If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

stylo: change to -moz-binding doesn't trigger frame reconstruction

RESOLVED FIXED

Status

()

Core
CSS Parsing and Computation
RESOLVED FIXED
3 months ago
2 months ago

People

(Reporter: xidorn, Assigned: heycam)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(2 attachments)

(Reporter)

Description

3 months ago
Specifically, dom/xbl/test/test_bug790265.xhtml is failing in Stylo but passing in Gecko. It seems the computed value of -moz-binding in this case is correct. It is not clear to me what leads to this failure.
(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #0)
> dom/xbl/test/test_bug790265.xhtml

bug 790265 (quoted testcase) sounds a bit similar to bug 1375969 ("dynamic change handling in XBL") for me as amateur.
Maybe this bug has become a duplicate of bug 1375969 ? Please just ignore this comment if it's unrelated.
(Reporter)

Comment 2

3 months ago
It could be. We will see when we try to run mochitests the next time I guess.
(Reporter)

Comment 3

2 months ago
This test still doesn't pass. So the issue here seems to be that CSS frame constructor isn't triggered for this change.

Looking at the code, I don't have idea immediately why this happens...

heycam, any idea?
Flags: needinfo?(cam)
Summary: stylo: XBL binding in content doesn't seem to work like in Gecko → stylo: change to -moz-binding doesn't trigger frame reconstruction
(Reporter)

Updated

2 months ago
Blocks: 1382078
(Assignee)

Comment 4

2 months ago
I guess the issue here is that the element is display:none, so we don't bother computing damage for the element, and instead fall back to the path that checks if display values has changed etc.  I'm not sure what the semantics of XBL bindings applied to display:none elements is, but I guess from this test that we at least need them to apply to roots of display:none subtrees.  (I'm not sure how we would ensure we load bindings applied to elements within display:none subtrees.)
Flags: needinfo?(cam)
(Assignee)

Updated

2 months ago
Assignee: nobody → cam
Status: NEW → ASSIGNED
(Assignee)

Comment 5

2 months ago
Some testing shows that Gecko doesn't apply bindings to elements within display:none subtrees, so handling it just on the display:none root should be fine.
(Reporter)

Comment 6

2 months ago
Oh, I didn't notice that it is a display:none...
(Assignee)

Comment 7

2 months ago
https://treeherder.mozilla.org/#/jobs?repo=try&revision=703cc4f4e0827b37dd5c63d91011d36ec870ab60
Comment hidden (mozreview-request)

Comment 9

2 months ago
mozreview-review
Comment on attachment 8889726 [details]
Bug 1375383 - style: Ensure we generate a ReconstructFrame hint when -moz-binding changes on a display:none root.

https://reviewboard.mozilla.org/r/160802/#review166092

Kinda sad we need this special case... r=me
Attachment #8889726 - Flags: review?(emilio+bugs) → review+
(Assignee)

Comment 10

2 months ago
(In reply to Emilio Cobos Álvarez [:emilio] from comment #9)
> Kinda sad we need this special case... r=me

XBL ¯\_(ツ)_/¯
(Assignee)

Comment 11

2 months ago
Created attachment 8889773 [details] [review]
Servo PR
(Assignee)

Comment 12

2 months ago
Merged.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.