1385729 - Fix uninterruptable reflow in ToolbarIconColor::inferFromText

Status: NEW

(Firefox :: Toolbars and Customization, defect, P3)

Description

[Dão Gottwald [:dao]]

[Tracking Requested - why for this release]: flaky first paint

(In reply to Kris Maglione [:kmag] from comment #20)
> (In reply to Dão Gottwald [::dao] from comment #19)
> > (In reply to :Gijs from comment #7)
> > > How do we avoid this leading to flashes of 'wrong' icons (plus first loading
> > > the wrong icons, then the right ones) ?
> > 
> > This seems like a valid concern, I was going to say the same.

I do see this now.

> I've been thinking about that too, and was planning to mention it as a
> precaution when I post to firefox-dev about these helpers.
> 
> In this particular case, I haven't been able to trigger any noticeable
> flickering, so I think it's worth the risk for the sake eliminating an extra
> 3.5ms layout flush before first paint (on my test machine, anyway). If it
> turns out to be problematic, I think we should be able to store initial
> values in the xulCache or startup cache to at least limit the cases where we
> see a flicker or have to force a layout flush.

Comment 1

[Kris Maglione [:kmag]]

I'll re-land the first two patches in bug 1383367 on their own, since the third part keeps getting backed out for conflicts anyway, and then handle the third part with the flickering fixed here.

Comment 2

[Gerry Chang [:gchang]]

Track 56+ as new regression.

Comment 3

[Kris Maglione [:kmag]]

The regression was backed out in the original bug due to merge conflicts, so there's no need to track this for 56.

Comment 4

[:Gijs (he/him)]

Should we track and/or try to fix this for 57?

Comment 5

[Dão Gottwald [:dao]]

(In reply to :Gijs from comment #4)
> Should we track and/or try to fix this for 57?

No, see comment 3 for why this doesn't need to be tracked (still applies to 57). It's a minor perf issue and not a regression (since this bug was morphed in comment 3). Kris might still try to fix this, but I'm not sure how.