Closed Bug 952191 Opened 7 years ago Closed 7 years ago

Australis Customization doesn't work if the window is too small

Categories

(Firefox :: Toolbars and Customization, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 29

People

(Reporter: mkaply, Assigned: jaws)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [Australis:P3])

Attachments

(2 files)

If you resize the browser window smaller and select Customize, the customization window is not visible or cutoff.

Also, the URL bar and everything is cutoff (versus resized), and on Mac, the fullscreen icon appears over the customize tab.

I'm not sure what the right thing to do is here, but it makes for some really bad UI.
Whiteboard: [Australis:P3]
I thought we had a minimum window size for this?
Flags: needinfo?(jaws)
We should make the label at the top of that page wrap so we don't hit this so early.
Flags: needinfo?(jaws)
The minimum window size is usable when we use our overflowable toolbars, but we disable the overflowable toolbar code when in customization mode. I agree with comment #2.
Attached patch Patch r=mattnSplinter Review
Assignee: nobody → jaws
Status: NEW → ASSIGNED
Attachment #8361627 - Flags: review+
Attachment #8361627 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/1e3e66429cce
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
QA Contact: cornel.ionce
Reproduced with Nightly from 2013-12-18.
I can see improvements with Firefox 29 beta 4 (Build ID: 20140331125246) on Windows 7 x64, Ubuntu 12.04 x32 and Mac OS X 10.9:
Mozilla/5.0 (X11; Linux i686; rv:29.0) Gecko/20100101 Firefox/29.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:29.0) Gecko/20100101 Firefox/29.0

I say improvements because if I make the browser a little smaller than in the attachment, I can see again this issue as per: http://i61.tinypic.com/dz6ky1.jpg
Is there a browser minimum width so that the Customization window is properly displayed?
Flags: needinfo?(jaws)
We have a browser minimum width that is applied when not in customization mode, however we don't change this minimum width when customization mode is entered. It is something we should probably think about doing. Can you file a separate bug for this?
Flags: needinfo?(jaws)
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #8)
> We have a browser minimum width that is applied when not in customization
> mode, however we don't change this minimum width when customization mode is
> entered. It is something we should probably think about doing. Can you file
> a separate bug for this?
Flags: needinfo?(alexandra.lucinet)
I've logged Bug 993299 for the issue mentioned by Alexandra in comment 7 and CC'ed you.
Flags: needinfo?(alexandra.lucinet)
Still able to reproduce this on Fx 29 beta 8 (build ID: 20140414143035), latest Nightly and latest Aurora.

There is a minimum width set for the customization mode verified in bug 993299 but if the user will resize the browser window to be smaller and then enter Customize Mode, the customization window is cut off as you can see in Mike's attachment.

If the user tries to resize the window afterwards, it will automatically jump to the minimum set width.

Could we implement the browser to automatically use the minimum width when entering Customize mode if the window size is smaller before it?
Flags: needinfo?(jaws)
Flags: needinfo?(gijskruitbosch+bugs)
We could probably do something with JS to force this, but I don't think a CSS-only solution is possible. I'm inclined to say that this particular nuance won't get fixed as it will introduce some more code paths that are not likely to be noticed if broken in the future.
Flags: needinfo?(jaws)
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #12)
> We could probably do something with JS to force this, but I don't think a
> CSS-only solution is possible. I'm inclined to say that this particular
> nuance won't get fixed as it will introduce some more code paths that are
> not likely to be noticed if broken in the future.

Concur. On top of that, forcing the window to be larger, potentially larger than the screen, can have all kinds of other sad consequences.

I think we just need to make the buttons at the bottom of the toolbox/palette wrap. That's non-trivial (and has its own bug filed) but will be a better way of making sure this is easier to use for small windows.
Flags: needinfo?(gijskruitbosch+bugs)
Marking issue verified based on comment 12 and comment 13.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.