Open Bug 498768 Opened 11 years ago Updated 6 years ago

Customized toolbar buttons not saved if window closed before customize dialog


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

Not set




(Reporter: MattN, Unassigned)




(Whiteboard: [FFT3.5])

From litmus test case 7007.  The changes made in step 3 are not saved so on restart, the toolbar is back to the previous state.

Tested on Mac and Linux
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1pre) Gecko/20090610 Firefox/3.5pre

Confirmed on Windows as well.
Keywords: dataloss
Is this a regression?
Adding [FFT3.5] in whiteboard.  Came across this issue during RC1 testing
Whiteboard: [FFT3.5]
It seems like that since the fix from bug 408268 landed we regressed again? We should check this.
Severity: normal → major
Flags: wanted1.9.1.x?
I have disabled the testcase on Litmus for now because it will always fail. After the fix it should be re-enabled.
Flags: in-litmus?
It still exists back to Firefox and eventually earlier. Probably an issue since it has been implemented.
Version: 3.5 Branch → 2.0 Branch
It definitely did work when I fixed bug 408268. So it's probably regressed since then. I thought the point of a litmus test was that we were supposed to detect this when the regression happened :(
Jonas, can you give me a date and changeset id on CVS when it has been checked in? So we need to check again for the regression range.

No-one guarantees that this subgroup is covered by testers. Even the subgroup was unowned for a while. I've taken the ownership now and hopefully we can avoid those not seen issues in the future now.
Patch was checked in on april 6th or 7th 2008.

However I do now remember that the original bug was that if you closed the window while customizing the toolbar, you'd *loose* *all* your buttons. The fix made it so that we simply reverted and no changes were saved.

I don't know if that's what the litmus test checks for though. But I do think that is ok behavior.
so since this is kinda wontfix, can the regression keywords be removed?
Done. I'm also not sure the 'dataloss' keyword really applies since the only data lost is recent configurations, which doesn't seem like it's bad enough to qualify.

Don't feel strongly about it though so left it for now.

It seems to me that what we should do here is ensure that there is a litmus test for what was fixed in bug 408268 (i.e. "all buttons disappear"), and then close this bug as WONTFIX.
Thanks Jonas. With your last comments I had another look into the Litmus test and yes, the expected behavior is described in a wrong way. We have to update the test.

But before we close this bug we should ask the UX team how we have to handle this on OS X. Since all dialogs support instant apply to any changes how should we behave with the customize toolbar? Alex, can you please lend us a helping hand? Thanks!
Keywords: datalossuiwanted
This should be instant apply on all platforms, since the user is visually seeing what their current toolbar layout is, it doesn't make sense if it were to revert for any reason (other than clicking restore default set).  Also, all platforms are currently using a single "done" button (as opposed to OK/Cancel/Apply) which indicates that the changes will be instant apply.
Thanks Alex! So it makes the bug valid for all platforms. Asking for blocking1.9.2.
Flags: blocking-firefox3.6?
Version: 2.0 Branch → Trunk
This isn't a recent regression and behavior is actually *better* in 1.9.1, aiui, so we won't consider this wanted for 1.9.1.x.
Flags: wanted1.9.1.x?
Flags: blocking-firefox3.6? → blocking-firefox3.6-
Flags: in-litmus?
The Firefox 29 redesign (code named "Australis") switched to an in-content page
for customization and rewrote the customization code.

Oh, the memories of Firefox 3.5 FFTs as an intern…
You need to log in before you can comment on or make changes to this bug.