Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upClears #5909 #7302
Clears #5909 #7302
Conversation
highfive
commented
Aug 21, 2015
| } | ||
| }; | ||
| match self.fragments.fragments[0].specific { | ||
| SpecificFragmentInfo::Canvas(_) => has_stacking_context = has_stacking_context && true, |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Adenilson
Aug 21, 2015
Author
Contributor
Looks to be the case for "|| true" or simple set has_stacking_context = true;
I'm assuming that we need a stacking context when there is Canvas?
|
@bors-servo: r+ |
|
|
…cwalton Clears #5909 Recent changes on Fragment::establishes_stacking_context() makes this hack no longer necessary for displaying filtered inline elements. <!-- Reviewable:start --> [<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7302) <!-- Reviewable:end -->
|
|
|
hack no longer necessary for displaying filtered inline elements. Interestingly, Acid1 will panic with index out of bounds. Now we test for Fragments vector length before reading it.
e000b74
to
508979e
|
I was able to reproduce the error in OSX, more info: https://gist.github.com/Adenilson/4eb3ab62247ffbc625b8 I applied a check for the Fragments vector length and it stops the panic from happening. |
|
That solves the case for acid1, I'm investigating what is wrong with the other 2 tests. |
…king_context().
|
Did some digging, the failing tests have associated SC (Stacking Context) but won't draw correctly. It seems that the original 'stacking_context && something_something' was required to turn to false the stacking_context flag. Otherwise the element won't be displayed. It is a bit unclear if that is thanks to Paint code or past DL (Display List) optimization. I also noticed that there is no need for checking the Canvas fragment presence, as it is already done as a special case in Fragment::establishes_stacking_context(). The current patch removes this unnecessary check and documents this issue. I executed all the 354 ref tests to make sure that there is no regression. |
|
Anyone could kick the bots on this one? |
|
r? @pcwalton |
|
|
|
@mrobinson Is this fixed now with your stuff? |
|
@pcwalton I think that this requires a further fix, which is to also integrate stacking contexts into the list of inlines. I've started working on that today, though I think it will be a multi-stage process. |
|
What is the status of this? |
|
I think that #8376 makes this PR unnecessarily. It fixes the issue that I mention in my comment. Additionally, it turns out that inlines with stacking contexts belong in the list of positioned content to match what other browsers do. |
Adenilson commentedAug 21, 2015
Recent changes on Fragment::establishes_stacking_context() makes this hack no longer necessary for displaying filtered inline elements.