> On May 14, 2019, at 2:43 PM, Dave Townsend <dtowns...@mozilla.com> wrote: > > Which test files are we talking about here? If they are testing UI widgets, > and our long-term goal is to use html and not xhtml for the UI then those > tests should, at some point, be in html.
It's worth breaking the tests down into groups to consider separately. After going through this in more detail and based on discussion coming out of this post, it makes me think the variation where we do a blanket rename of all .xul files to .xhtml might be a better option - it'd certainly be less work at least. Here are some of the groups of tests I see: "Reftests" (Number: 364) These are probably mostly safe to migrate, but there could be different CSS applying on elements (for instance if the root node is <html:html> and not <xul:window>). For that reason I think we could go straight to .xhtml (step 4) and then selectively apply the step 5 cleanups as long as they don't break tests. "Crashtests" (Number: 147) I think I'd go straight to .xhtml (step 4), and probably not even do any step 5 cleanups. The reasoning is we don't want to go through each test one by one and decide if we are losing test coverage by making those changes. “Mochitests that are specifically testing XML features” (Number: ???) These would need to go straight to .xhtml (step 4) and then selectively apply the step 5 cleanups as long as they don't break tests. "Mochitests that test built-in widgets" (Number: ~160) I'm using tests in the `toolkit/content/tests/chrome` folder as a proxy for this. As you mention, we might want these to live in the same document the browser does (which will be xhtml, at least for now). Though in general something a widget that works in .xhtml should also work in .html - the breakage would mostly go the other way (i.e. if a widget relied on the prototype cache parser ignoring whitespace could work in xhtml but not in html). So I think you could argue either way - going straight to .xhtml would maintain the status quo. "Mochitests that don't care about the test document" (Number: ???) One example that I had envisioned going straight to .html are the mochitest-chrome tests in xpfe: https://bugzilla.mozilla.org/show_bug.cgi?id=1548152. I picked this folder as a starting point because there are only two tests there (https://searchfox.org/mozilla-central/source/xpfe/appshell/test/test_hiddenPrivateWindow.xul and https://searchfox.org/mozilla-central/source/xpfe/appshell/test/test_windowlessBrowser.xul), and as far as I can tell there's nothing in them that cares whether the test document itself is xul, xhtml, or html. This is primarily the type of test I had in mind for (3). My suspicion is that there are a lot of tests of that type across the tree. The trick will be finding them - Brendan has a script to find the most common DOM patterns across all the tests, and there are 32 other tests that match that exact DOM structure: https://gist.github.com/bgrins/22a448034748340042bdbf499e219a71#file-25-top-repeated-structures-txt-L426. It's not a guarantee that all of them would be safe to migrate, but spot-checking other tests there it seems to be the case. There are a bunch of other shared DOM structures that seem to be in a similar boat. Brian > On Tue, May 14, 2019 at 1:48 PM Brian Grinstead <bgrinst...@mozilla.com> > wrote: > There isn't any particular reason functionally to go to one vs the other but > I think we still generally prefer to get to plain .html if possible. The > reasoning is that it's more common and understood by engineers and tooling. > It also doesn't have XML-specific additions like CDATA in script tags. > > That said, after talking through this again with Brendan we realized it may > not end up being worth the effort for existing test files. If we were able to > apply some of the incremental changes from step 5 to test .xhtml files that > may be good enough. If the cost was low to include step 3 (like, if we had a > tool that mostly automated away the process) then I’d prefer to do it. But it > could be pragmatic to skip step 3 (at least for test documents). We’ll be > working on some tooling anyway for step 5, so will spend a bit of time seeing > how hard it looks to be to automate the html doc conversion. > > Brian > > > On May 14, 2019, at 12:37 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: > > > > On 5/14/19 11:32 AM, Brian Grinstead wrote: > >>> 3. For files where there are no (important) XUL elements in the > >>> markup, rename .xul->.html. > > > > Brian, > > > > Could you expand on why this is preferable (when possible) to renaming them > > to .xhtml? Are there benefits to .html over .xhtml for our purposes here? > > Is this mostly around how we deal with our tests, as opposed to actual > > parts of the UI? > > > > In general, the plan sounds great! > > > > -Boris > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
