Closed Bug 1074890 Opened 7 years ago Closed 7 years ago
Hovering "Other Actions" button temporarily makes the UI jiggle around some px
+++ This bug was initially created as a clone of Bug #511625 +++ "Other Actions" button is the button that should never have been created like that in the first place. It's a messy unprofessional thing. STR 1) With mouse, hover over the "Other actions" button in message header, move in and out of the buttons area. Actual result Entire surrounding UI including the header button itself moves around by some px. - header pane height reduces by some px (this bug) - header button caption moves some px to upper-right corner (not sure if this might be intended or technically required, but it doesn't look nice imo) Expected result Hovering the button shouldn't move around any UI elements - header pane should keep steady in same height - imo header button caption shouldn't move while hovered, looks flimsy and unstable. Or perhaps it's an intended 3D effect that somebody needs to explain to me (ymmv).
Thomas, where do you see this jiggling? I tested on XP Luna/Classic, Win7 Aero/Classic, Win8 default/HC, Linux and OS X and saw no jiggling. On XP it should be fixed with Bug 525628.
I see it both on TB24.6.0 and TB 31.1.2, Windows XP with Windows XP (OS) theme with Farb scheme blue (green start button with slightly rounded edges and corners, blue task bar). I remember *not* seeing the bug under the same circumstances on some messages today, but it occurs for almost all messages. So maybe the other bug fixed this only for the Win XP Classic (OS) theme, but not the genuine Windows XP (OS) Theme?
It works for me on Luna blue. You surely tested it in safe mode. Please can you check when you see it and when not to find a cause of this issue?
I also tested in TB safe mode, yes. Here's an important detail which might cause this, and also reminds me of a similar problem we recently solved elsewhere (Bug 966655): I have Windows dpi scaling activated for my high resolution screen, so everything is magnified: in my case, screen resolution of 1920 x 1080 Pixels, magnified at 150% (144 dpi). As observed in Bug 966655, dpi scaling interaction with xul might be flawed, or exposing problems which at 100% scaling aren't noticed or occuring. Richard, can you try to change AND apply to 150% AND 300% dpi scaling, then restart TB with scaling applied, and see if you can reproduce this bug? 300% (or more if possible) because depending on screen size, perhaps problem only shows from certain threshold upwards...
I noticed dpi scaling because I suddenly saw a useless scrollbar appearing on message reader header pane after clicking "10 more..." but there was nothing to scroll, even scrollbar just movable maybe by 1px... I think we need to look into this in a dedicated bug which seeks to test every area of our UI how it reacts to screen dpi scaling...
Wow, tricky, not sure why I'm always spotting those extra tricky bugs but perhaps it's because they know I'll track them down no matter what... Here's more pieces to the puzzle (but not complete yet, don't have time to produce test cases): One and the same message can expose the problem of this bug or not, and I can reproduce like this (on some messages, but not all): (on a plaintext bmo message; probably not relevant) Look at msg subject and adjust msg reader width and height so that the subject does NOT wrap to multiple lines. -> as long as subject is NOT wrapped, bug occurs. Now reduce the message reader area so that subject DOES wrap -> as long as subject is wrapped, bug does NOT occur. Now in my test cases, wrapped subject also has scrollbar (potentially suggesting that bug might occur if there's no scrollbar); however, on short message which don't show scrollbar (but has long subject), bug not seen. Unfortunately it needs more testing, because that last message does never show the bug even if subject is NOT wrapped... Note to self for identifying my test messages: * exposing the bug if subject not wrapped: Subject: [Bug 966655] Scrollbar shown for recipient list when empty Date: 28.08.2014, 09:58 (4,5 kb) * not exposing the bug, even if subject not wrapped: Subject: approval-comm-esr31 granted: [Bug 966655] Scrollbar shown for recipient list when empty : [Attachment 8480093 [details] [diff]] Patch v.1b: Add 2px extraHeight to msgHeadersToolbar Date: 28.08.2014, 12:14 (3,3 kb) So we'll need testcases here, but I don't have time for that right now. As another odd bug in the same corner, depending on circumstance, hovering the "Other actions" button actually changes subject wrapping for me (in TB safe mode), so the subject starts to jump around even though the message reader pane size is stable :( To get that, adjust message reader pane size so that subject wraps, and shrink until last word "foo" of row 1 wraps down into line 2. Then hover "Other actions" -> "foo" jumps back into row 1 again. Tell me what you want, we have design flaws here, XUL, TB bugs or whatever.
This looks again like I mentioned already in bug 966655 to be a toolkit bug where the scaling isn't correctly done on all levels (with, height, margin, padding etc.). This issue here is also because this button is styled hacky by non-hover appearance: none and manually setting border width and on hover appearane: button with system border setting which differs in width on upscaled screens. Bug 511625 will be the best solution to fix this issue with also removing the hacky code.
I mark this bug as WFM with the changes in bug 511625.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.