Closed Bug 983632 Opened 6 years ago Closed 6 years ago

[Australis, Windows HiDPI] button icons can be completely hidden but still be on toolbar and not in overflow menu if window resized/width decreased

Categories

(Firefox :: Toolbars and Customization, defect)

x86_64
Windows 8.1
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 30
Tracking Status
firefox29 --- verified
firefox30 --- verified

People

(Reporter: aryx, Assigned: jaws)

References

(Blocks 1 open bug)

Details

(Whiteboard: [Australis:P3])

Attachments

(2 files)

Attached image screenshot of issue
Nightly and Aurora 20140313 on Windows 8.1 Pro (OS level font size 125%)

When the browser window's width gets decreased, it is possible that the icon of a button gets completely hidden, but some of clickable area is still available (see screenshot).

In my humble opinion, the button should get added to the overflow. E.g. after the icon getting partially hidden, or at a threshold (like 50%).
Can you provide STR? On OS X and Linux, we have a recent regression bug filed, where the QA person who reported it said it's not reproducible on Windows, so...
Flags: needinfo?(archaeopteryx)
(other bug is bug 983562)
See Also: → 983562
(In reply to :Gijs Kruitbosch from comment #1)
> Can you provide STR?
1. Create new profile and launch it (window opens not maximized).
2. Reduce window width.
Flags: needinfo?(archaeopteryx)
Sigh.
Summary: [Australis] button icons can be completely hidden but still be on toolbar and not in overflow menu if window resized/width decreased → [Australis, Windows HiDPI] button icons can be completely hidden but still be on toolbar and not in overflow menu if window resized/width decreased
I expect this is a core bug with overflow events, considering that I can't reproduce on 100% DPI but can on 125% (and Jared reproduced on 200% DPI).
Whiteboard: [Australis:P3]
Jared said he's looking at this. :-)
Assignee: nobody → jaws
I looked for the regression range and this has been present since Australis merged to mozilla-central.
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=beddd6d4bcdf&tochange=ba9ecdea3a90

I think this has something to do with overflowing at a slow pace, because that's the only way that I can reproduce it. My guess is that our calculations for determining if something is overflowing don't trigger if it's only a couple pixels, whereas if you resize the window quickly then this bug doesn't appear.
Attached patch PatchSplinter Review
Attachment #8391240 - Flags: review?(gijskruitbosch+bugs)
Status: NEW → ASSIGNED
Attachment #8391240 - Flags: review?(gijskruitbosch+bugs) → review+
https://hg.mozilla.org/integration/fx-team/rev/d7e5a58a314d
Whiteboard: [Australis:P3] → [Australis:P3][fixed-in-fx-team]
Duplicate of this bug: 983562
https://hg.mozilla.org/mozilla-central/rev/d7e5a58a314d
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [Australis:P3][fixed-in-fx-team] → [Australis:P3]
Target Milestone: --- → Firefox 30
Comment on attachment 8391240 [details] [diff] [review]
Patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Australis' overflowable toolbar
User impact if declined: sometimes the toolbar doesn't overflow correctly because we don't get overflow events
Testing completed (on m-c, etc.): on m-c
Risk to taking this patch (and alternatives if risky): very low
String or IDL/UUID changes made by this patch: none

NB: uplifting this is important if we uplift bug 980879.
Attachment #8391240 - Flags: approval-mozilla-aurora?
Attachment #8391240 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Keywords: verifyme
Reproduced the initial issue on Surface Pro 2 (Windows 8.1 64bit) using Aurora from 2014-03-14, 125% and 200% DPI, verified as fixed using Firefox 29 RC and latest Aurora.
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.