Closed
Bug 1024269
Opened 10 years ago
Closed 10 years ago
Win64 REFTEST TEST-UNEXPECTED-FAIL | file:///C:/slave/test/build/tests/reftest/tests/layout/reftests/dom/multipleinsertionpoints-appendsingle-2.xhtml | image comparison (==), max difference: 255, number of differing pixels: 104
Categories
(Core :: XBL, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1026008
People
(Reporter: away, Unassigned)
References
Details
https://tbpl.mozilla.org/php/getParsedLog.php?id=41405495&tree=Date
I assume the first five failures there share a common cause.
Comment 1•10 years ago
|
||
The failures look like we've got the completely wrong content, rather than being e.g. a painting glitch.
e.g. the first failing test, multipleinsertionpoints-appendsingle-2.xhtml, has "21" instead of "12" on the first line, and the second has
21
5
3
4
...whereas the reference has...
12
3
4
5
CC'ing tn, who wrote these tests (in http://hg.mozilla.org/mozilla-central/rev/699e6f9a3660 ) & may have some insight.
Depends on: lazyfc
Are these supposed to behave differently in the test environment or something? When I simply load up multipleinsertionpoints-appendsingle-2.xhtml, both win32 and win64 give me:
3
1
4
5
2
Comment 3•10 years ago
|
||
Yeah, these testcases use XBL, which is disabled unless you set the pref described in https://developer.mozilla.org/en-US/docs/Using_Remote_XUL
(That pref is set for the reftest environment, and it's also enabled for chrome-privileged content, I believe.)
Comment 4•10 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #1)
> The failures look like we've got the completely wrong content, rather than
> being e.g. a painting glitch.
>
> e.g. the first failing test, multipleinsertionpoints-appendsingle-2.xhtml,
> has "21" instead of "12" on the first line, and the second has
> 21
> 5
> 3
> 4
That ordering is really odd. Obviously XBL is doing something because it pulls the 2 to the start, but in a different order then in in tree before xbl is applied. And then the order of the remaining elements just makes no sense. And the strangest thing is that these tests are passing on win32. Is XBL putting the children in the correct order? Or are we constructing the frames in the wrong order now for some reason? Who knows about XBL these days?
Comment 5•10 years ago
|
||
I don't have any ideas offhand.
The way to debug this would be to inspect the DOM in both the win32 and win64 case (to determine if it's a DOM issue or a layout issue). Script from the content scope isn't going to be able to see the anonymous content. The simplest thing is probably just to load this as chrome so that you'll both be able to apply the binding without setting any prefs (see comment 3) and be able to use document.getAnonymousNodes.
Comment 6•10 years ago
|
||
It appears to be a problem with the DOM. The DOM Inspector shows the span containing the "2" before the one containing the "1" in a win64 build I downloaded, win32 builds have it correct. Also forcing a full reconstruct (by toggling display: none on/off on an ancestor) doesn't fix the problem, so unlikely to be a problem with incremental frame construction updates.
Component: Layout → XBL
Comment 7•10 years ago
|
||
Indeed, and Neil filed the correct bug for us already.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Comment 8•10 years ago
|
||
Bug 1026008 has merged to m-c, is it possible to verify the fix on TBPL?
Comment 9•10 years ago
|
||
The tests are fine, the bug was in XBL code, so removing dependency on the bug that added the tests.
No longer depends on: lazyfc
Reporter | ||
Comment 10•10 years ago
|
||
(In reply to neil@parkwaycc.co.uk from comment #8)
> Bug 1026008 has merged to m-c, is it possible to verify the fix on TBPL?
This failure no longer appears on the latest Date push. Thanks for the fix!
https://tbpl.mozilla.org/?tree=Date&rev=a2b84c34f2e1
You need to log in
before you can comment on or make changes to this bug.
Description
•