1378275 - stylo: I don't think we do any nsIDocument::FlushPendingLinkUpdates.

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, enhancement)

Description

[Emilio Cobos Álvarez (:emilio)]

I've seen some visited state coming out late on my nightly, and I think this is the case. Gecko does it both while restyling and while constructing frames.

Presumably we want to do it before any restyling goes on, I guess.

I suppose this can end up calling ContentStateChanged (maybe only off a runnable)? That part may be tricky.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #0)
> I've seen some visited state coming out late on my nightly, and I think this
> is the case.

The cause, ofc.

Comment 2

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

You may want to see bug 1361618, which currently intends to go the opposite way: removing these steps from the Gecko version.  

:bz and I discussed this during the SF all hands and concluded from reading the code that the existing calls don't appear to actually do much, but it's also tricky to have confidence about it given the async behavior.

Comment 3

[Boris Zbarsky [:bzbarsky]]

The code from the existing calls registers with places.

If the document's runnable (which I think runs at idle) is noticeably laggy to the point where users would notice the slowness in things turning visited, then that would be a problem for the plan from bug 1361618.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

(In reply to Boris Zbarsky [:bz] (vacation until 7/7) from comment #3)
> The code from the existing calls registers with places.
> 
> If the document's runnable (which I think runs at idle) is noticeably laggy
> to the point where users would notice the slowness in things turning
> visited, then that would be a problem for the plan from bug 1361618.

I think what I was seeing is links already visited before not being styled as visited when they should... And coming out as visited eventually (later). I don't have a consistent way to repro though, so until I can prove it probably you can disregard it.

Comment 5

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Hmm, so far I can't reproduce a visually noticeable difference between Stylo and Gecko here.

I've been testing with the following URL:

https://treeherder.mozilla.org/#/jobs?repo=try&tochange=99aad6003e458e83404cb756f9192529e9a50c06&fromchange=641e3d6dda053a48371484e86530d15b9268333f

Roughly 50% of the time, visited links are already colored before they appear, and the other 50% of the time there's a 500ms delay before visited coloring appears.  I see the same behavior distribution with both Stylo and Gecko.

Comment 6

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Ah, forgot to mention I tested on both macOS and Linux, just in case it was platform specific.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #5)
> Hmm, so far I can't reproduce a visually noticeable difference between Stylo
> and Gecko here.
> 
> I've been testing with the following URL:
> 
> https://treeherder.mozilla.org/#/
> jobs?repo=try&tochange=99aad6003e458e83404cb756f9192529e9a50c06&fromchange=64
> 1e3d6dda053a48371484e86530d15b9268333f
> 
> Roughly 50% of the time, visited links are already colored before they
> appear, and the other 50% of the time there's a 500ms delay before visited
> coloring appears.  I see the same behavior distribution with both Stylo and
> Gecko.

Yeah, sorry for not replying to this. I'm pretty sure what I was observing on my nightly was one of the multiple animation-related and visited-related bugs that we've fixed recently.