in bug #406259, Robert writes: "when you open a new window, the green triangle flashes before being replaced in the url bar" I'm able to reproduce this with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b2pre) Gecko/2007121008 Minefield/3.0b2pre Note, I'm using proto 0.8

I can see this on Windows, too.

This ensures that the Star and Go icons won't be displayed at the same time.

dao, with your fix: 1) if I configure my prefs so that I show my home page on a new window (or starting up), I see the green arrow and then the (yellow) star. 2) if I configure my prefs so that I open a blank page, I don't see the star, but I do see some movement, which I think is the splitter between the url bar and the search box appearing. (I wonder if we fix that, would we see a Ts / Txul win?)

3) on a related note, should we have the green "go" arrow if there is nothing in the url bar?

(In reply to comment #3) > dao, with your fix: > > 1) if I configure my prefs so that I show my home page on a new window (or > starting up), I see the green arrow and then the (yellow) star. We only display the star if [pageproxystate="valid"]... so that's by design. > 2) if I configure my prefs so that I open a blank page, I don't see the star, > but I do see some movement, which I think is the splitter between the url bar > and the search box appearing. (I wonder if we fix that, would we see a Ts / > Txul win?) It's in delayedStartup right now, moving it to BrowserStartup would be a Ts/Txul loss if anything. But I'll use this opportunity to advocate bug 393733 one again... let's get rid of the permanent splitter :) SetPageProxyState("invalid") is in delayedStartup, too, by the way, which is what my patch works around. (In reply to comment #4) > 3) on a related note, should we have the green "go" arrow if there is nothing > in the url bar? Maybe as an indicator that you can/should start typing now... dunno.

>> 1) if I configure my prefs so that I show my home page on a new window (or >> starting up), I see the green arrow and then the (yellow) star. > > We only display the star if [pageproxystate="valid"]... so that's by design. Do you mean because we are first loading about:blank, and then my homepage? Note, without your patch, I see the white star, then the green arrow, then the yellow star.

Comment on attachment 292481 [details] [diff] [review] patch r=sspitzer

"if I configure my prefs so that I show my home page on a new window (or starting up), I see the green arrow and then the (yellow) star." this would happen on session restore, too. Dao, do you think this is worthy of a spin off bug?

(In reply to comment #6) > >> 1) if I configure my prefs so that I show my home page on a new window (or > >> starting up), I see the green arrow and then the (yellow) star. > > > > We only display the star if [pageproxystate="valid"]... so that's by design. > > Do you mean because we are first loading about:blank, and then my homepage? There's some delay between starting the request and onLocationChange being called (which sets pageproxystate to "valid"), depending on your connection. > Note, without your patch, I see the white star, then the green arrow, then the > yellow star. Without the patch you should see the star *and* the arrow for a split second, then then arrow, then the star. But I don't know if the proto theme is doing something odd. (In reply to comment #8) > "if I configure my prefs so that I show my home page on a new window (or > starting up), I see the green arrow and then the (yellow) star." > > this would happen on session restore, too. Dao, do you think this is worthy of > a spin off bug? Session restore should be faster if the data is loaded from cache, which should be the case most of the time... I don't know if there's something to speed up significantly. But in any case I think it's expectable that it takes a non-zero time before pageproxystate is valid. I also think displaying the star depending on this state is the right thing to do.

Checking in browser/base/content/browser.xul; /cvsroot/mozilla/browser/base/content/browser.xul,v <-- browser.xul new revision: 1.400; previous revision: 1.399 done