Restarting Firefox resets the toolbar customizations

VERIFIED FIXED in mozilla2.0b9

Status

()

Toolkit
Toolbars and Toolbar Customization
P2
normal
VERIFIED FIXED
7 years ago
6 years ago

People

(Reporter: Ori Avtalion (salty-horse), Assigned: dao)

Tracking

Trunk
mozilla2.0b9
Points:
---
Bug Flags:
in-testsuite +
in-litmus -

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: explanation in comment 14)

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

7 years ago
Starting with the 2010-03-17 nightlies, every time a different nightly is ran on a profile, the toolbar customizations are reset.

To reproduce:
1) Download the nightly build from 2010-03-17.
2) Run it on a new profile, e.g. "toolbar".
3) Customize the toolbars and add a "Downloads" button next to the home icon.
4) Restart the browser -- the icon is in place. Close the browser
5) Download and run the 2010-03-18 on the "toolbar" profile.
6) The "Downloads" button will be gone. The customizations will be reset to the defaults.

Making the change on any nightly from 03-17+ and then testing on it on *any other* nightly from that group will cause the customizations to reset.
Can you please tell us your complete user agent string so we will know which branch you are using? thanks.
(Reporter)

Comment 2

7 years ago
I'm using:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a4pre) Gecko/20100322 Minefield/3.7a4pre

The nightlies to test were downloaded from the "mozilla-central" builds, e.g.:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010-03-19-03-mozilla-central/firefox-3.7a4pre.en-US.linux-x86_64.tar.bz2
Status: NEW → UNCONFIRMED
Ever confirmed: false
Changeset for both builds:

PASS: http://hg.mozilla.org/mozilla-central/rev/16a974dd72e1
FAIL: http://hg.mozilla.org/mozilla-central/rev/2cc5ad2cf917

Changes: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=16a974dd72e1&tochange=2cc5ad2cf917

I can't find a check-in which plays in that area. Dao, could the tabbed browsing changes be related somehow?
Version: unspecified → Trunk
(Assignee)

Comment 4

7 years ago
(In reply to comment #3)
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=16a974dd72e1&tochange=2cc5ad2cf917
> 
> I can't find a check-in which plays in that area. Dao, could the tabbed
> browsing changes be related somehow?

Which tabbed browsing changes specifically?

Has anyone reproduced this in a profile without extensions?
(Assignee)

Updated

7 years ago
Duplicate of this bug: 553395
(Assignee)

Updated

7 years ago
Duplicate of this bug: 554310
(In reply to comment #4)
> Which tabbed browsing changes specifically?

I think of bug 347930.

> Has anyone reproduced this in a profile without extensions?

When you test in Safe Mode please also check if the regression range above is correct. Thanks.
Keywords: regression, regressionwindow-wanted
OS: Linux → All
Hardware: x86_64 → All

Comment 8

7 years ago
(In reply to comment #6)
> *** Bug 554310 has been marked as a duplicate of this bug. ***

As mentioned in Bug 554310, I first started seeing this in the win32 Minefield/Trunk nightly of 20100317 ((Build: Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.9.3a4pre) Gecko/20100317 Minefield/3.7a4pre - Build ID:
20100317041424 built from http://hg.mozilla.org/mozilla-central/rev/16a974dd72e1).

The most consistent time of occurrence is when starting Minefield after a cold bootup--cold bootup being turning on the computer after being shut off like I do overnight.

Also, as I have stated in Bug 554310, I have not been able to isolate this to a particular extension. I did disable all extensions and one by one re-enabled them. Each time, the toolbar did not reset. (In my testing, I placed a flexible space between the stop and reload buttons to force both of them to show and removed from the nav toolbar the Home button which I do not use.)

In the Add-Mgr. all installed extensions appear to be enabled. Those that add Status Bar items are there and functional. Extension-added menu items are still there and functional. (I have used the Restart Minefield File menu item that MR Tech Toolkit provides.)

What is not available are any toolbar buttons that extensions add in the Customize... dialog and thus are not available to add to the nav toolbar.

However, if/when this does crop up, a simple restart "fixes" things except that I still have to redo my nav toolbar customizations.

What is different about starting Minefield after a cold boot versus restarting from within the browser and closing and then starting it, again?

Comment 9

7 years ago
this happens for me also after installing/uninstalling/enabling/disabling add-ons

Comment 10

7 years ago
Note: I opened/closed bugzilla # 553395 because I was seeing the same problem.  I was able to isolate it to a particular extension: Hostname In Toolbar 1.06 and it's interaction with Dictionary Tooltip.  I'm not sure what the fix was for Hostname In Toolbar but the fix resolved the problem.  It sounds like there may be otheer extensions that may have uncovered this bug.

Comment 11

7 years ago
Other extensions indeed do seem to be related to this bug, from what Mozillazine users are reporting.  Extensions that triggered this include PDF Download, Intelligent Middle Clickums, AutoPager Lite, Zoom Page, Firesomething, and Titlebar Tweaks.  Some of those are woefully out of date (but still worked), while others did work with previous 3.7a versions, so there's no correlation I see on that end.
(In reply to comment #7)
> (In reply to comment #4)
> > Which tabbed browsing changes specifically?
> 
> I think of bug 347930.

Dao, did this make the Wed Mar 17 build?
Summary: Using different versions of firefox resets the toolbar customizations → Restarting Firefox resets the toolbar customizations
(Assignee)

Comment 13

7 years ago
(In reply to comment #12)
> (In reply to comment #7)
> > (In reply to comment #4)
> > > Which tabbed browsing changes specifically?
> > 
> > I think of bug 347930.
> 
> Dao, did this make the Wed Mar 17 build?

Yes.
(Assignee)

Comment 14

7 years ago
The problem or part of it appears to be that extensions trigger the toolbar constructors before XUL overlays for <toolbarpalette id="BrowserToolbarPalette"> are loaded. Consequentially all extension items are missing. Just accessing gNavToolbox early enough triggers this, and so does accessing gBrowser since the tab strip is in a toolbar.

(In reply to comment #10)
> I was able to isolate it to a particular extension: Hostname In Toolbar 1.06
> and it's interaction with Dictionary Tooltip.  I'm not sure what the fix was
> for Hostname In Toolbar but the fix resolved the problem.

The fix for "Hostname in Titlebar" looks like this:

>-hostnameInTitlebar.setUpdateTitlebar();
>+window.addEventListener("load", function() { hostnameInTitlebar.setUpdateTitlebar(); }, false);

The first thing hostnameInTitlebar.setUpdateTitlebar does is to access document.getElementById("content"), i.e. gBrowser.
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Component: Toolbars and Toolbar Customization → XUL
Ever confirmed: true
Keywords: regression, regressionwindow-wanted
Product: Toolkit → Core
QA Contact: toolbars → xptoolkit.widgets
(Assignee)

Updated

7 years ago
Blocks: 347930
Hmm, I can see why accessing gBrowser would run the TabsToolbar constructor, but why does it affect the other toolbars as well?

Comment 16

7 years ago
Is it possible to move tabContextMenu out from tabbrowser-tabs and put it into 
mainPopupSet.

there are many extensions that add menu item into tabContextMenu
Bug 554165 will help that by re-adding an mStrip accessor for compat, and adding a gBrowser.tabContextMenu property.
(Assignee)

Comment 18

7 years ago
(In reply to comment #15)
> Hmm, I can see why accessing gBrowser would run the TabsToolbar constructor,
> but why does it affect the other toolbars as well?

The toolbar being constructed first sets toolbox.palette and removes the toolbarpalette element from the document.

Comment 19

7 years ago
As the author of the Hostname in Titlebar extension, I feel obliged to post my findings while fixing this bug.

I received an e-mail from a noble user (siegfre) who told me this problem was most likely related to using the Dictionary Tooltip add-on in conjunction with my add-on.

Experimenting with the Firefox 3.7a4pre build revealed that on a clean build, installing Hostname in Titlebar would *usually* cause the toolbar customizations to be lost at the first next start of Firefox, though *usually* they would be OK again at subsequent launches. It also sometimes occurred that after a few restarts the customizations were still not back.

So to me, whether or not it will work, seems just a timing issue. Though I don't know enough about Firefox' internals to judge with more accuracy.

I'm not quite sure what causes this behavior, but found a workaround nonetheless. However, I am still curious to find the cause of the issue.
(Assignee)

Comment 20

7 years ago
(In reply to comment #19)
see bug 554279
(Assignee)

Comment 21

7 years ago
(In reply to comment #20)
> (In reply to comment #19)
> see bug 554279

Uh, sorry, we're in bug 554279... I thought you commented somewhere else.
(In reply to comment #16)
> Is it possible to move tabContextMenu out from tabbrowser-tabs and put it into 
> mainPopupSet.

Filed bug 554991 for that.
This bug is annoying enough that I finally decided to uninstall all of my add-ons, which then I don't see this issue with a default install with standard custom icons.
Dao, have you accidentally removed the regression keyword?
(Assignee)

Comment 25

7 years ago
No. The underlying issue is not a regression. See comment 14.
(Assignee)

Comment 26

7 years ago
This comment seems relevant, especially bz's addition:

> If we have not yet displayed the document for the first time
> (i.e. we came in here as the result of a dynamic overlay load
> which was spawned by a binding-attached event caused by
> StartLayout() on the master prototype - we must remember that
> this overlay has been merged and tell the listeners after
> StartLayout() is completely finished rather than doing so
> immediately - otherwise we may be executing code that needs to
> access XBL Binding implementations on nodes for which frames
> have not yet been constructed because their bindings have not
> yet been attached. This can be a race condition because dynamic
> overlay loading can take varying amounts of time depending on
> whether or not the overlay prototype is in the XUL cache. The
> most likely effect of this bug is odd UI initialization due to
> methods and properties that do not work.
> XXXbz really, we shouldn't be firing binding constructors
> until after StartLayout returns! 

http://hg.mozilla.org/mozilla-central/annotate/87f8bdc77722/content/xul/document/src/nsXULDocument.cpp#l3216
(In reply to comment #25)
> No. The underlying issue is not a regression. See comment 14.

I have to admit, the user-facing issue is a major regression. Does it really matter if a change on our end made the "non-regression" part that _causes_ the user-facing part to be MUCH MUCH more common?

I'd still consider this a regression due to that.

Comment 28

7 years ago
on the latest builds, restarting twice seems to restore the lost toolbar customizations

Updated

7 years ago
Duplicate of this bug: 557603
blocking2.0: ? → final+
Priority: -- → P2

Comment 30

7 years ago
As reported and summarized, this is a regression.  I suppose you could say it depends on a XUL bug that is not a regression.
Keywords: regression
(Assignee)

Comment 31

7 years ago
(In reply to comment #30)
> As reported and summarized, this is a regression.

No, the bug as summarized was there before. See bug 557603 for instance.

> I suppose you could say it
> depends on a XUL bug that is not a regression.

There's no such separate bug, and I don't think we need one, it's this one (see product and component).
Keywords: regression
Whiteboard: explanation in comment 14

Comment 32

7 years ago
This bug reproduces (almost) always with Tree Style Tab extension enabled.

Comment 33

7 years ago
(In reply to comment #32)
> This bug reproduces (almost) always with Tree Style Tab extension enabled.

I have this bug without Tree Style Tab extension

Comment 34

7 years ago
when its bug will be fix, guys?

Comment 35

7 years ago
maybe its help, toolbar resets to default when I'm using all in  one sidebar or gmail notifer. When they are torn off all is ok.

Comment 36

7 years ago
Ithis bugs is better in 4.0b1 (the toolbar resets itself only when I add new addon or update existing one) but in 4.0b2 candidate 1 the toolbar resets itself after each restart

Comment 37

7 years ago
Since Bug 568691 - Use manifests and data tables to register XPCOM components landed, I have not seen this bug on my WinXP system. Prior to this landing, when I updated my nightly or added/updated any add-ons, my toolbars would reset forcing me to restart the browser another time so I could then redo my toolbar buttons and their arrangement.

Comment 38

7 years ago
Created attachment 460137 [details]
testcase extension

This testcase extension is *WRONG*. 

Prior to completion of DOM browser.xul, the extension accesses property of browser element. 

Toolbar will be reset due to this wrong extension.

Comment 39

7 years ago
Many extension such as "Hostname In Toolbar" extension  is wrong.
And such wrong extension are registered in AMO.

These wrong extension did not consider completion of DOM (ex. window.addEventListener('load',xxxx, false);)

So, I think this is extension's issue.

Comment 40

7 years ago
@Alice0775 White:
Allow me to correct you on that: the latest version of my Hostname in Titlebar addon actually uses the addEventListener() method.

Comment 41

7 years ago
Well, if this is an extension issue, then that needs to be communicated more effectively to extension authors.
(Assignee)

Comment 42

7 years ago
It's triggered by extensions, but it's not clear that extensions behaving this way /should/ trigger this bug. See comment 14 and comment 26.

Comment 43

7 years ago
(In reply to comment #42)
> It's triggered by extensions, but it's not clear that extensions behaving this
> way /should/ trigger this bug. See comment 14 and comment 26.

I'm not sure if my observations are relevant, but I recently bought a new Win7 computer prior to the landing of Bug 568691 I mentioned in Comment 37 above. It is much faster than my WinXP system. I did not see this bug in my newer system, so, FWIW, this suggests that individual system processing speed is a factor with this bug.
(In reply to comment #38)
> Created attachment 460137 [details]
> testcase extension
> 
> This testcase extension is *WRONG*. 

So, the problem is triggered when add-ons access certain browser elements before the load event. This is clearly a regression because it never happened before. However, if there's no way to return things to exactly the same way they were before, I would agree with making these add-ons break, rather than let them break the UI due to bad practices. FWIW, all XUL tutorials I've seen use the load event instead of just running the code when the file is loaded.

We are already communicating many breaking changes for Firefox 4, and we can add this to the list when we know what needs to be changed.
(Assignee)

Comment 45

7 years ago
(In reply to comment #44)
> (In reply to comment #38)
> > Created attachment 460137 [details] [details]
> > testcase extension
> > 
> > This testcase extension is *WRONG*. 
> 
> So, the problem is triggered when add-ons access certain browser elements
> before the load event. This is clearly a regression because it never happened
> before.

It did happen before. Please read the comments previously made in this bug.
I did read all the comments before posting. Which one are your referring to?
(Assignee)

Comment 47

7 years ago
comment 14, comment 26, comment 31.
Does that mean you have reproduced this bug in 3.6?
(Assignee)

Comment 49

7 years ago
As far as I remember, back in March I reproduced this in older builds, possibly in 3.6, by accessing gNavToolbox early.

Comment 50

7 years ago
comment #32, comment #33
Tree Style Tab really caused this problem on Minefield 4.0b2pre, and it was fixed on TST 0.10.2010070301. (This was verified by Alice0775.)
changeset: http://www.cozmixng.org/retro/projects/piro/changesets/6796

Comment 51

7 years ago
(In reply to comment #36)
> Ithis bugs is better in 4.0b1 (the toolbar resets itself only when I add new
> addon or update existing one) but in 4.0b2 candidate 1 the toolbar resets
> itself after each restart

It has happened so far occasionally to me in 4.0b4,on restart after choosing the "remember windows & tabs from last time" option (and then just clicking exit,not "save & quit"),some extensions buttons were lost and the bookmarks button was relocated to the right edge of the toolbar - it has however never happened in the previous releases I've been using (b2 and b3:not sure about b2,but b3 had exactly the same extensions installed).

(In reply to comment #35)
> maybe its help, toolbar resets to default when I'm using all in  one sidebar or
> gmail notifer. When they are torn off all is ok.

This made me think that I have the Feed sidebar extension,but I also had it in b3 and this toolbar resetting did never happen,not once.

Comment 52

7 years ago
It also seems related in some way (or,they often happen at the same time) to this other bug https://bugzilla.mozilla.org/show_bug.cgi?id=590381 
in which ,with two windows each with multiple tabs (one window also including app tabs),tabs freeze on browser restart-as far as I can tell,tab freezing has always been linked to toolbar resetting,but toolbar resetting can also happen on its own.

Comment 53

7 years ago
I've just register to Bugzilla, i'm not a bug fixer or something like that. But i want to say: because of this malfunction/bug? i made and app to replace localstore.rdf with my own customized file before each startup. Then, the toolbar shows the right icons on each startup. I looks like the problem is when Firefox is closing or when an icon is added (i don't know the last one) and not when Firefox is loading (If that what is said in <a href="show_bug.cgi?id=554279#c14">comment 14</a>? if not, sorry my mistake)
> ...if there's no way to return things to exactly the same way
> they were before, I would agree with making these add-ons break, rather than
> let them break the UI due to bad practices. FWIW, all XUL tutorials I've seen
> use the load event instead of just running the code when the file is loaded.

They are probably breaking toolbar settings for the other extensions as well, that's the problem. For example, when I encounter that unpleasant effect in Firefox 4 beta 4, I loose all toolbar buttons, it does not matter if they were from uncompatible extensions, or compatible, or dragged on (or out of) the toolbar by me manually.
Keywords: dev-doc-needed
I wasn't having this problem very often with the nightly builds of Minefield up until about a week ago and now every time the browser is restarted, my stop/reload button is moved back to the default position, various extension buttons I've placed right of the search box are gone (even missing from the customize pop up).

Updated

7 years ago
Duplicate of this bug: 608379

Comment 57

6 years ago
Hi all,
This bug is still present in Minefield 4.08bpre. It always resets my toolbar. Additionally, what is frustrating is that everytime, I start up Minefield 4.08bpre, updater runs and it "updates" to Minefield 4.08bpre. Installs and then my toolbar customizing is lost. 

Is there a solution to this ?
Here is some troubleshooting information:

  Application Basics

        Name
        Firefox

        Version
        4.0b8pre

        User Agent
        Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101213 Firefox/4.0b8pre


  Extensions

        Name        					Version        Enabled        ID

        Launchy        					4.4.0        	true        launchy@gemal.dk

        PDF Download   					3.0.0.1      	true        {37E4D8EA-8BDA-4831-8EA1-89053939A250}

        Download Statusbar      			0.9.7.2        	true        {D4DD63FA-01E4-46a7-B6B1-EDAB7D6AD389}

        Mozilla Labs: Prospector - Find Suggest    	4        	true        find.suggest@prospector.labs.mozilla

        Mozilla Labs: Prospector - Speak Words     	3        	true        speak.words@prospector.labs.mozilla

        Mozilla Labs: Prospector - Query Stats     	2.2        	false        query.stats@prospector.labs.mozilla

        NoScript        				2.0.7        	true        {73a6fe31-595d-460b-a920-fcc0f8843232}

        Mozilla Labs: Prospector - Instant Preview        2        	true        instant.preview@prospector.labs.mozilla

        Omnibar        					0.7.2.20100912	false        omnibar@ajitk.com

        Gmail Watcher        				1.30        	false        gmailwatcher@sonthakit

        Adblock Plus        				1.3.2        	true        {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}

  Modified Preferences

      	Name      							Value

        browser.places.smartBookmarksVersion        			2

        browser.startup.homepage_override.buildID        		20101213030326

        browser.startup.homepage_override.mstone        		rv:2.0b8pre

        browser.tabs.warnOnClose        				false

        extensions.lastAppVersion        				4.0b8pre

        network.cookie.prefsMigrated        				true

        places.history.expiration.transient_current_max_pages        	63363

        privacy.sanitize.migrateFx3Prefs        			true

        security.disable_button.openCertManager        			false

        security.enable_ssl2        					true

        security.warn_viewing_mixed        				false

  Graphics

        Adapter Description
        NVIDIA Quadro NVS 140M

        Vendor ID
        10de

        Device ID
        0429

        Adapter RAM
        128

        Adapter Drivers
        nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um

        Driver Version
        8.16.11.8694

        Driver Date
        9-5-2009

        Direct2D Enabled
        true

        DirectWrite Enabled
        true

      GPU Accelerated Windows
      1/1 Direct3D 10


Thanks and Regards,
Ravi

Comment 58

6 years ago
(In reply to comment #57)
Are you still seeing this with a clean profile?

Comment 59

6 years ago
(In reply to comment #58)
> (In reply to comment #57)
> Are you still seeing this with a clean profile?

Seems unlikely, given that this bug is known to be triggered by extensions. However, I don't think further comments reporting the issue are needed - it seems the cause is understood already, and the bug is not fixed yet.

Comment 60

6 years ago
(In reply to comment #59)
> (In reply to comment #58)
> > (In reply to comment #57)
> > Are you still seeing this with a clean profile?
> 
> Seems unlikely, given that this bug is known to be triggered by extensions.
> However, I don't think further comments reporting the issue are needed - it
> seems the cause is understood already, and the bug is not fixed yet.

It would be at least helpful if the offending extension could be reported.
Not a blocker.

Is this really a XUL bug? Comment 14 doesn't give a reason for why it is.
blocking2.0: final+ → -

Comment 62

6 years ago
(In reply to comment #61)
> Not a blocker.
> 
> Is this really a XUL bug? Comment 14 doesn't give a reason for why it is.

If we're knowingly allowing extensions to trigger this, then this is most certainly a blocker. Especially if we're relying on extensions to delay certain code initialisation to avoid this.

Comment 63

6 years ago
I cannot imagine how "restarting Firefox resets toolbar customizations" is not a blocker (and I doubt that is what was meant). This is a serious issue, and the effect of it has become a lot more serious since 3.6, even if the fact that there was previously less serious symptoms caused by the same underlying code problem means that this doesn't technically qualify as a regression.

Would it help to leave this bug and file a new clean bug to consider what to do for Firefox 4?
To be clear, as a core XUL bug this is not a blocker (and imo is wontfix).  This sounds like just a contradictory set of assumptions being made by extensions and some of our UI bindings.  Maybe we can fix the latter to not make those assumptions; Dão would know better than I.  If so, this bug should be moved to Toolkit, presumably, right?
Moving this to toolkit so that it doesn't fall between the cracks.
blocking2.0: - → ?
Component: XUL → Toolbars and Toolbar Customization
Product: Core → Toolkit
QA Contact: xptoolkit.widgets → toolbars

Comment 66

6 years ago
> Dão Gottwald      2010-03-24 12:43:15 PDT
> 
> (In reply to comment #15)
>> Hmm, I can see why accessing gBrowser would run the TabsToolbar constructor,
>> but why does it affect the other toolbars as well?
> 
> The toolbar being constructed first sets toolbox.palette and removes the
> toolbarpalette element from the document.

Dão,

The seamonkey toolbar bindings puts the palette initialization code in the toolbox binding:

<http://mxr.mozilla.org/comm-central/source/suite/common/bindings/toolbar.xml?mark=80-82#69>

Would this help? We also don't remove the <toolbarpalette> from the DOM removing the need to null check various stuff such as gURLBar.
(Assignee)

Comment 67

6 years ago
(In reply to comment #66)
> > Dão Gottwald      2010-03-24 12:43:15 PDT
> > 
> > (In reply to comment #15)
> >> Hmm, I can see why accessing gBrowser would run the TabsToolbar constructor,
> >> but why does it affect the other toolbars as well?
> > 
> > The toolbar being constructed first sets toolbox.palette and removes the
> > toolbarpalette element from the document.
> 
> Dão,
> 
> The seamonkey toolbar bindings puts the palette initialization code in the
> toolbox binding:
> 
> <http://mxr.mozilla.org/comm-central/source/suite/common/bindings/toolbar.xml?mark=80-82#69>
> 
> Would this help?

The toolbar constructor accesses the toolbox, so that wouldn't make a difference.

> We also don't remove the <toolbarpalette> from the DOM
> removing the need to null check various stuff such as gURLBar.

Wouldn't help, as the toolbars would still be populated before the overlays are loaded.
(Assignee)

Comment 68

6 years ago
Created attachment 497612 [details] [diff] [review]
patch

This seems to help. (Thanks for the test extension, Alice!)
I sent this to the try server. I wouldn't be surprised if it breaks some tests.
I also wouldn't be surprised if it breaks extensions making assumptions about when toolbars are initialized...
blocking2.0: ? → final+
(Assignee)

Comment 69

6 years ago
Created attachment 497683 [details] [diff] [review]
patch

I thought pageshow fired before load, but it doesn't... readystatechange does.
Attachment #497612 - Attachment is obsolete: true
(Assignee)

Updated

6 years ago
Attachment #497683 - Flags: review?(enndeakin)

Comment 70

6 years ago
Comment on attachment 497683 [details] [diff] [review]
patch

The test doesn't check this bug right?
Attachment #497683 - Flags: review?(enndeakin) → review+
(Assignee)

Comment 71

6 years ago
Created attachment 497706 [details] [diff] [review]
patch (test added)

test_toolbar.xul wasn't testing this. I also didn't want to add complexity there, so I added a dedicated test for this.
Attachment #497683 - Attachment is obsolete: true
Attachment #497706 - Flags: review?(enndeakin)
(Assignee)

Updated

6 years ago
Assignee: nobody → dao
Status: NEW → ASSIGNED
Keywords: dev-doc-needed

Updated

6 years ago
Attachment #497706 - Flags: review?(enndeakin) → review+
(Assignee)

Comment 72

6 years ago
http://hg.mozilla.org/mozilla-central/rev/e9b1ad4ad23b
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b9

Updated

6 years ago
Duplicate of this bug: 597373
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10pre) Gecko/20110121 Firefox/4.0b10pre.

Dao, I assume we don't need a manual test here in favor of the automated one which has been checked-in. If not please request in-litmus addition.
Status: RESOLVED → VERIFIED
Flags: in-litmus-

Comment 75

6 years ago
This bug has returned in Firefox 4 and also Firefox 5.

I have firefox 5, 32 bit version on Windows 7 and I had this problem with both 4 and 5. I have even created a new FF profile and it did not help.

I customize my toolbar, add a few buttons from "Google toolbar" and replace the toolbar with Google's. After restart everything has returned to beginning.

These guys here confirm the bug.

http://support.mozilla.com/en-US/questions/808671
You need to log in before you can comment on or make changes to this bug.