In my main browsing profile, on the already-logged-in facebook main page, there's a bogus blue triangle pointing up from the "Create a post" chat-bubble, which is not supposed to be there. Screenshots coming up. It's only there if I set layout.css.servo.enabled to true. (If I set the pref to false and restart my browser, the blue arrow goes away; then if I set the pref to true and restart, it's back.) I can't reproduce in a fresh profile with the servo pref flipped, so there must be some other interaction. I'll dig in more tomorrow to see if I can come up with concrete STR...

Inspector shows that the blue triangle comes from this element, which is nested several levels inside of an <a>: <span class="_4-h8"></span> ...and specifically, it's supposed to come from a pseudo-element inside of that span, which has these styles applied: ========== ._4-h8::after { border-bottom: 8px solid rgb(255, 255, 255); border-left: 8px solid transparent; border-right: 8px solid transparent; content: ""; left: -8px; position: absolute; top: 1px; } [...] Inherited from a: a { color: rgb(54, 88, 153); cursor: pointer; } ========== The "border-bottom" style there is notably white -- it's supposed to draw a white triangle (pointing upwards) as the bottom border for that element. But instead of drawing it as white, it draws the border using the "color" property that it inherited from the "a" ancestor!! I've verified that if I adjust the color on the "a" rule there, then this triangle changes color accordingly. ALSO: if I untick & retick the checkbox for the |content: ""| declaration in devtools (in a session that's showing the issue), then the issue goes away.

(I'm using Linux Nightly 56.0a1 (2017-07-13) (64-bit) on a Thinkpad P50 laptop, for the record.)

Nightly 56 x64 20170713100259 @ Debian Testing (Linux 4.11.0-1-amd64, Radeon RX 480) Main profile: I didn't saw it at first. I clicked into it and then on the german equivalent for "Photo/Video Album" where I got the file selection dialog which I closed then. Then I saw this visual bug. Sometimes I only clicked into and beside it and saw it, sometimes with F5 after this. With the linux x64 debug build from bug 1371450 comment 13 with a fresh profile and doing above steps I finally got a tab crash after I clicked into that now buggy comment/post field and beside it: > [Child 1638] WARNING: stylo: HasStateDependentStyle always returns zero!: file /home/worker/workspace/build/src/layout/style/ServoStyleSet.cpp, line 869 > thread '<unnamed>' panicked at 'Resolving style on element without current styles with lazy computation forbidden.', /home/worker/workspace/build/src/servo/ports/geckolib/glue.rs:2759 The tab crash may not be related, but I have no idea what I am talking about. Maybe just F5 is enough to trigger this.

(In reply to Darkspirit from comment #4) > Nightly 56 x64 20170713100259 @ Debian Testing (Linux 4.11.0-1-amd64, Radeon > RX 480) > Main profile: I didn't saw it at first. I clicked into it and then on the > german equivalent for "Photo/Video Album" where I got the file selection > dialog which I closed then. Then I saw this visual bug. Sometimes I only > clicked into and beside it and saw it, sometimes with F5 after this. > > With the linux x64 debug build from bug 1371450 comment 13 with a fresh > profile and doing above steps I finally got a tab crash after I clicked into > that now buggy comment/post field and beside it: > > [Child 1638] WARNING: stylo: HasStateDependentStyle always returns zero!: file /home/worker/workspace/build/src/layout/style/ServoStyleSet.cpp, line 869 > > thread '<unnamed>' panicked at 'Resolving style on element without current styles with lazy computation forbidden.', /home/worker/workspace/build/src/servo/ports/geckolib/glue.rs:2759 This is really bad. This is a case that I can't yet catch in bug 1371450..

(In reply to Hiroyuki Ikezoe (:hiro) from comment #5) > (In reply to Darkspirit from comment #4) > > Nightly 56 x64 20170713100259 @ Debian Testing (Linux 4.11.0-1-amd64, Radeon > > RX 480) > > Main profile: I didn't saw it at first. I clicked into it and then on the > > german equivalent for "Photo/Video Album" where I got the file selection > > dialog which I closed then. Then I saw this visual bug. Sometimes I only > > clicked into and beside it and saw it, sometimes with F5 after this. > > > > With the linux x64 debug build from bug 1371450 comment 13 with a fresh > > profile and doing above steps I finally got a tab crash after I clicked into > > that now buggy comment/post field and beside it: > > > [Child 1638] WARNING: stylo: HasStateDependentStyle always returns zero!: file /home/worker/workspace/build/src/layout/style/ServoStyleSet.cpp, line 869 > > > thread '<unnamed>' panicked at 'Resolving style on element without current styles with lazy computation forbidden.', /home/worker/workspace/build/src/servo/ports/geckolib/glue.rs:2759 > > This is really bad. This is a case that I can't yet catch in bug 1371450.. This panic will be fixed in bug 1378064.

Still in Nightly 56 x64 20170717100212 @ Debian Testing (Linux 4.11.0-1-amd64, Radeon RX480). Also seen in the "Linux x64 Stylo opt" try build from bug 1381431 comment 4.

"Linux x64 Stylo debug" from bug 1381431 comment 4: bug is still visible. > [Child 9868] WARNING: stylo: HasStateDependentStyle always returns zero!: file /home/worker/workspace/build/src/layout/style/ServoStyleSet.cpp, line 890 > thread '<unnamed>' panicked at 'Restyle damage should be empty if the element was not restyled', /home/worker/workspace/build/src/servo/ports/geckolib/glue.rs:2746 tab crash with this while testing this bug. Don't have competence to say if it's related.

(In reply to Darkspirit from comment #8) > "Linux x64 Stylo debug" from bug 1381431 comment 4: bug is still visible. > > [Child 9868] WARNING: stylo: HasStateDependentStyle always returns zero!: file /home/worker/workspace/build/src/layout/style/ServoStyleSet.cpp, line 890 > > thread '<unnamed>' panicked at 'Restyle damage should be empty if the element was not restyled', /home/worker/workspace/build/src/servo/ports/geckolib/glue.rs:2746 > tab crash with this while testing this bug. Don't have competence to say if > it's related. It is bug 1381420, seems the cause of this bug.

Can't reproduce the visual issue from comment 0 in Nightly 56 x64 20170720100139 @ Debian Testing (Linux 4.11.0-1-amd64, Radeon RX480), but I didn't test yesterday, so I can't say if bug 1378064 was the fix. If I press Ctrl+F5 and then click on Photo/video, the triangle is hidden for a moment (when the file selection dialog appears), but this behavior is the same with and without Stylo.

I can confirm this is fixed in latest Nightly (with Stylo enabled). I used mozregression to track down the fix range: 5:55.90 INFO: First good revision: 113bdc4b5ab6987ea4f8205a4eae4d085a4107f9 5:55.90 INFO: Last bad revision: 242989927622ef557614c2cce320ff82aed43b45 5:55.90 INFO: Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=242989927622ef557614c2cce320ff82aed43b45&tochange=113bdc4b5ab6987ea4f8205a4eae4d085a4107f9 Emilio Cobos Álvarez — servo: Merge #17762 - style: Cascade the visited style with the normal rules if we didn't find a relevant link (from emilio:visited-nested); r=jryans I can see why that might've changed the behavior here, because this blue triangle is inside of an <a href="#"> element. And indeed, that gave me the missing piece of the STR -- from a fresh profile, I can reproduce this (in broken nightlies e.g. from 2017-07-13) if I follow the steps in comment 0 here *AND ALSO* visit https://www.facebook.com/# (including the hash), to make that URL count as "visited". So Emilio's merge (to change :visited handling) is definitely the fix here. Emilio, how should we track/resolve this bug to reflect that?

That patch was part of bug 1381276 (I guess I forgot to mention it in that commit message). I'll dupe it to that bug.

Thanks! Clearing dependency list, then. (I think they were just suspected-dependencies -- but to the extent that they are actual dependencies, they could be transferred over to the dupe-target.)

That's good to know! (I am hoping bug 1381420 does not cause any visual faults.)