Closed Bug 873048 Opened 11 years ago Closed 11 years ago

Test what happens when previously removed items are made no longer removable.

Categories

(Firefox :: Toolbars and Customization, defect)

x86_64
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: mconley, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [Australis:M5])

The back/forward button, URL bar, and stop/reload buttons will change so that they are no longer removable by default from the nav-bar.

We might want to write a migration to put those items back into the nav-bar. We have to be careful here in deciding how to proceed, as some power-users may have moved these items out on purpose.

I think we're most concerned with these items being in the palette somehow. Not sure how to deal with the possibility of them being in other toolbars just yet.
(In reply to Mike Conley (:mconley) from comment #0)
> We might want to write a migration to put those items back into the nav-bar.

The patch in bug 866978 already handles this.

> I think we're most concerned with these items being in the palette somehow.

Ditto.

> Not sure how to deal with the possibility of them being in other toolbars
> just yet.

Ditto.

> We have to be careful here in deciding how to proceed, as some power-users
> may have moved these items out on purpose.

This is the only thing that isn't covered nicely by bug 866978. I *think*, if such a widget had been moved to another toolbar, it will end up at the end of the nav-bar. Might be able to change that so it keeps its original position as defined in the XUL markup.
This was accidentally assigned to the UI Customization "user".
Assignee: customization-ui → nobody
(In reply to Blair McBride [:Unfocused] (Limited availability.) from comment #1)
> (In reply to Mike Conley (:mconley) from comment #0)
> > We might want to write a migration to put those items back into the nav-bar.
> 
> The patch in bug 866978 already handles this.
> 

Awesome.

> > I think we're most concerned with these items being in the palette somehow.
> 
> Ditto.
> 

Splendid.

> > Not sure how to deal with the possibility of them being in other toolbars
> > just yet.
> 
> Ditto.
> 

Fantastic!

> > We have to be careful here in deciding how to proceed, as some power-users
> > may have moved these items out on purpose.
> 
> This is the only thing that isn't covered nicely by bug 866978. I *think*,
> if such a widget had been moved to another toolbar, it will end up at the
> end of the nav-bar. Might be able to change that so it keeps its original
> position as defined in the XUL markup.

Alright, I'll keep this bug open to deal with that case.
Depends on: 866978
Summary: Write a migration to put non-removable items back into their respective toolbars. → Test what happens when previously removed items are made no longer removable.
I just tested this now that bug 866978 has landed.

In a new profile on Release Firefox, I customized my reload button away, and then put my URL bar into the tab strip, and the stop, back and forward buttons into the menubar.

When I opened that profile using UX Nightly, it "did the right thing", and the items were put back into the nav-bar.

So I think we have this case covered.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.