It looks like the post lost formatting on the way - most importantly the
numbers next to each step and nesting in the list. I made a formatted
version of this post at
https://docs.google.com/document/d/1rEPcu7ei-kK5Dvt7sBgqa_vP37QFIUtVd33JkCK1mvM/edit
.
Here's a (hopefully) fixed version of the list:
1. Load all XUL documents as XHTML using the prototype cache. This doesn’t
require any file renaming, we will just detect a .xul file and act like
it’s .xhtml. This is tracked in bug 1550801. There are only a few known
changes required to make this work properly, for example:
a) Fixup calls to `document.createElement` to
`document.createXULElement` since the default namespace will now be HTML
(Bug 1551320).
b) Remove any remaining references to XULDocument. Most of these have
been removed already, but there are some callers that didn’t apply to the
main browser document that haven’t been removed yet (Bug 1551344)
c) This does _not_ require changing whitespace aware API callers (i.e.
calls to .childNodes->.children), since the prototype cache drops
whitespace in both XUL and XHMTL.
2. Delete the XULDocument implementation.
3. For files where there are no (important) XUL elements in the markup,
rename .xul->.html. This requires doing at least:
a) Fixup whitespace-aware API callers (i.e. calls to
.childNodes->.children).
b) Write a tool to parse and automatically convert these documents as
much as possible. For instance, stop using self closing tags, migrate
`<xul:window>`->`<html>`, convert ProcessingInstruction stylesheets to
`<link>`, etc.
c) Update bugs and comments referencing the old file name
4. For files that don’t match the heuristics from (3), rename .xul->.xhtml.
This is simpler than (3), since we don’t have to worry about whitespace
aware API, parsing issues, etc. In this case everything should work
identically with the file name changed. The main extra task here is:
d) Update bugs and comments referencing the old file name
5. For the now-xhtml documents from (4), apply a subset of changes from
(3). For instance, migrate `<xul:window>`->`<html>`, convert
ProcessingInstruction stylesheets to `<link>`, etc).
On Tue, May 14, 2019 at 8:24 AM Brian Grinstead <bgrinst...@mozilla.com>
wrote:
> To prepare for browser.xhtml (bug 1533881
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1533881>), we’ve been
> smoothing over differences between XUL documents and chrome HTML documents
> (bug
> 1453783 <https://bugzilla.mozilla.org/show_bug.cgi?id=1453783>). We are
> now working out a plan for removing XUL documents entirely from
> mozilla-central (bug 1540278
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1540278>). There are
> currently around 1530 xul documents in the tree
> <https://github.com/bgrins/xul-analysis/blob/master/file-lists/2019-05-09.txt>
> and around 1400 of these are in test directories.
>
> We’re early in the process right now but wanted to circulate the plan to
> let people know about upcoming changes and give a chance to provide
> feedback. If there aren’t objections, we think step 1 could be completed
> shortly after the merge (2019-05-20) and that we could start work on the
> following steps in short order. The outline of the plan is:
>
>
> 1. Load all XUL documents as XHTML using the prototype cache. This
> doesn’t require any file renaming, we will just detect a .xul file and act
> like it’s .xhtml. This is tracked in bug 1550801
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1550801>. There are only
> a few known changes required to make this work properly, for example:
> 1. Fixup calls to `document.createElement` to
> `document.createXULElement` since the default namespace will now be
> HTML (Bug
> 1551320 <https://bugzilla.mozilla.org/show_bug.cgi?id=1551320>).
> 2. Remove any remaining references to XULDocument. Most of these
> have been removed already, but there are some callers that didn’t apply
> to
> the main browser document that haven’t been removed yet (Bug 1551344
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1551344>)
> 3. This does _not_ require changing whitespace aware API callers
> (i.e. calls to .childNodes->.children), since the prototype cache drops
> whitespace in both XUL and XHMTL.
> 2. Delete the XULDocument implementation.
> 3. For files where there are no (important) XUL elements in the
> markup, rename .xul->.html. This requires doing at least:
> 1. Fixup whitespace-aware API callers (i.e. calls to
> .childNodes->.children).
> 2. Write a tool to parse and automatically convert these documents
> as much as possible. For instance, stop using self closing tags, migrate
> `<xul:window>`->`<html>`, convert ProcessingInstruction stylesheets to
> `<link>`, etc.
> 3. Update bugs and comments referencing the old file name
> 4. For files that don’t match the heuristics from (3), rename
> .xul->.xhtml. This is simpler than (3), since we don’t have to worry about
> whitespace aware API, parsing issues, etc. In this case everything should
> work identically with the file name changed. The main extra task here is:
> 1. Update bugs and comments referencing the old file name
> 5. For the now-xhtml documents from (4), apply a subset of changes
> from (3). For instance, migrate `<xul:window>`->`<html>`, convert
> ProcessingInstruction stylesheets to `<link>`, etc).
>
>
> A variation on this plan would be to move step 3 until after step 4 -
> essentially do a blanket rename of all .xul files to .xhtml shortly after
> step 1 stuck. This would make it faster to complete the removal of xul
> files from the tree and get out of the intermediate state where we have
> .xul files loaded as HTML documents. However, this would come at the cost
> of more filename churn - tests that are ultimately destined for .html would
> be renamed .xul->.xhtml->.html instead of only .xul->.html. Renaming files
> has a cost because it can break in-flight patches, make it harder to search
> history, and requires updating bugs referencing the old file name (for
> example, for intermittent tracking bugs
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1543834>). Because of that,
> we are recommending the outline as-is instead of the variation above.
>
> Thanks,
> Brian
>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
