Note: There are a few cases of duplicates in user autocompletion which are being worked on.

stylo: Facebook "Create a post" chat-bubble has an out-of-place blue triangle, in some browser profiles

VERIFIED DUPLICATE of bug 1381276

Status

()

Core
CSS Parsing and Computation
P2
normal
VERIFIED DUPLICATE of bug 1381276
8 days ago
21 hours ago

People

(Reporter: dholbert, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

8 days ago
Created attachment 8886442 [details]
screenshot of bug (blue triangle), taken in main browsing profile with Stylo enabled

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...
(Reporter)

Comment 1

8 days ago
Created attachment 8886443 [details]
screenshot of expected rendering
(Reporter)

Updated

8 days ago
(Reporter)

Comment 2

8 days ago
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.
(Reporter)

Comment 3

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

Comment 4

8 days ago
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.
Depends on: 1378064
Priority: -- → P2

Comment 7

3 days ago
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.

Comment 8

3 days ago
"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.
Depends on: 1381420

Comment 10

a day ago
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.
(Reporter)

Comment 11

a day ago
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?
Flags: needinfo?(emilio+bugs)
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.
Status: NEW → RESOLVED
Last Resolved: a day ago
Flags: needinfo?(emilio+bugs)
Resolution: --- → DUPLICATE
Duplicate of bug: 1381276
(Reporter)

Comment 13

a day ago
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.)
Status: RESOLVED → VERIFIED
No longer depends on: 1381420, 1378064
That's good to know! (I am hoping bug 1381420 does not cause any visual faults.)
You need to log in before you can comment on or make changes to this bug.