Last modified: 2014-03-26 23:34:52 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T59586, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 57586 - VisualEditor: Consider using document.implementation.createHTMLDocument() in ve.createDocumentFromHTML
VisualEditor: Consider using document.implementation.createHTMLDocument() in ...
Status: RESOLVED FIXED
Product: VisualEditor
Classification: Unclassified
Technical Debt (Other open bugs)
unspecified
All All
: Normal enhancement
: VE-deploy-2014-03-27
Assigned To: Roan Kattouw
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-26 13:24 UTC by Roan Kattouw
Modified: 2014-03-26 23:34 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Roan Kattouw 2013-11-26 13:24:20 UTC
To figure out:
* Does this work in all browsers we support? I have anecdotally confirmed support in Firefox 25 and Chrome 30
* Protocol-relative URLs in <base> are broken, because documents created this way don't have a creator context or whatever.

Benefits:
* Not a hack involving iframes :)
* Faster than the iframe hack
* Does not have issues with HTTPSEverywhere in Firefox

For the <base> issue, it looks like something like this will work:

>>> d.querySelector('base')
<base href=​"/​/​example.com">​
>>> d.baseURI
null
>>> d.querySelector('base').getAttribute('href')
"//example.com"
>>> d.querySelector('base').setAttribute('href', 'http://example.com');
undefined
>>> d.baseURI
"http://example.com/"
Comment 1 Roan Kattouw 2013-12-18 12:40:15 UTC
(In reply to comment #0)
> For the <base> issue, it looks like something like this will work:
>
I read the spec some more and it looks like the trick I outlined is actually something that the spec specifically covers and says should work.

Other issue: we can't parse doctypes or <html> tags this way, so we can't respect non-HTML5 doctypes and we won't see any attributes on the <html> element. This isn't a problem for Parsoid documents at this time, although it'll be pretty annoying if we ever want to respect things like <html lang="nl">.
Comment 2 Roan Kattouw 2014-02-19 22:50:10 UTC
...or use DOMParser, which actually does *precisely* what we want. We could use it in browsers where it's available as a replacement for ve.createDocumentFromHtml, because it's supported only in FF 12+, Chrome 30+ (!), IE 10+, Opera 17+ (!) and not at all (!!) in Safari.
Comment 3 Gerrit Notification Bot 2014-03-25 18:12:33 UTC
Change 120836 had a related patch set uploaded by Catrope:
Use DOMParser in ve.createDocumentFromHtml() if available

https://gerrit.wikimedia.org/r/120836
Comment 4 Roan Kattouw 2014-03-25 18:12:58 UTC
(In reply to Roan Kattouw from comment #2)
> ...or use DOMParser, which actually does *precisely* what we want. We could
> use it in browsers where it's available as a replacement for
> ve.createDocumentFromHtml, because it's supported only in FF 12+, Chrome 30+
> (!), IE 10+, Opera 17+ (!) and not at all (!!) in Safari.
This is what I ended up going with.
Comment 5 Gerrit Notification Bot 2014-03-26 23:19:11 UTC
Change 120836 merged by jenkins-bot:
Use DOMParser in ve.createDocumentFromHtml() if available

https://gerrit.wikimedia.org/r/120836

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links