-
Notifications
You must be signed in to change notification settings - Fork 26
Investigate failing math-element tree-construction tests #33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
So it turns out that Firefox is in fact failing these tests; see the following:
The reason I hadn’t previously realized that Firefox fails those is that I wasn’t correctly testing them when I tried to run them manually. I had tried them as normal parsing tests, but they’re actually fragment-parsing tests — so they need to be run through the fragment parser, with a particular element as the context element. And the reason the failures are going unnoticed as far as Firefox CI is that they’ve been flagged as expected failures: |
Analogous fragment parsing of SVG content exhibits the same bug; see html5lib/html5lib-tests#129 |
OK, I think I've managed to isolate the cause of this, and a possible fix. I'll test it more and see. Looking at the part of the code where I think the cause is, it's not clear to me yet how it maps to the current spec requirements. It's a code condition that was added 12 years ago, so I'm also going to look at the history to try to discern where it originally came from. |
I was mistaken — the code that I thought I’d isolated it to turned out to not actually be the cause after all. So I’m back to investigating it further. |
This change ensures that for all cases with spec requirements in the form “clear the stack back to a foo context” — which involves checking for elements with particular names — we only look for elements in the HTML namespace, rather than additionally looking for elements which aren’t in the HTML namespace but that also have those particular names. Otherwise, without this change, we aren’t in conformance with the spec requirements, and we fail several cases in the html5lib-tests suite. Fixes #33
OK, I finally managed to figure out the cause, and #42 has a fix. |
This change ensures that for all cases with spec requirements in the form “clear the stack back to a foo context” — which involves checking for elements with particular names — we only look for elements in the HTML namespace, rather than additionally looking for elements which aren’t in the HTML namespace but that also have those particular names. Otherwise, without this change, we aren’t in conformance with the spec requirements, and we fail several cases in the html5lib-tests suite. Fixes #33
This change ensures that for all cases with spec requirements in the form “clear the stack back to a foo context” — which involves checking for elements with particular names — we only look for elements in the HTML namespace, rather than additionally looking for elements which aren’t in the HTML namespace but that also have those particular names. Otherwise, without this change, we aren’t in conformance with the spec requirements, and we fail several cases in the html5lib-tests suite. Fixes #33
This change ensures that for all cases with spec requirements in the form “clear the stack back to a foo context” — which involves checking for elements with particular names — we only look for elements in the HTML namespace, rather than additionally looking for elements which aren’t in the HTML namespace but that also have those particular names. Otherwise, without this change, we aren’t in conformance with the spec requirements, and we fail several cases in the html5lib-tests suite. Fixes validator/htmlparser#33 Differential Revision: https://phabricator.services.mozilla.com/D122722
This change ensures that for all cases with spec requirements in the form “clear the stack back to a foo context” — which involves checking for elements with particular names — we only look for elements in the HTML namespace, rather than additionally looking for elements which aren’t in the HTML namespace but that also have those particular names. Otherwise, without this change, we aren’t in conformance with the spec requirements, and we fail several cases in the html5lib-tests suite. Fixes validator/htmlparser#33 Differential Revision: https://phabricator.services.mozilla.com/D122722
This change ensures that for all cases with spec requirements in the form “clear the stack back to a foo context” — which involves checking for elements with particular names — we only look for elements in the HTML namespace, rather than additionally looking for elements which aren’t in the HTML namespace but that also have those particular names. Otherwise, without this change, we aren’t in conformance with the spec requirements, and we fail several cases in the html5lib-tests suite. Fixes validator/htmlparser#33 Differential Revision: https://phabricator.services.mozilla.com/D122722
We’re failing four test cases in https://github.com/html5lib/html5lib-tests/blob/master/tree-construction/math.dat (see below). I don’t understand why the Java parser is failing these but the Firefox parser isn’t.
These seem related to whatwg/html@8cf34ad “Handle foster-parenting of and elements”, which as far as I can see, we maybe never implemented support for in the Java sources — in which case, it would be expected to see the tests failing just as I’ve observed them to be.
But if so, it’s again a mystery to me why these tests would be passing in Firefox but not when run with the Java parser.
The text was updated successfully, but these errors were encountered: