Closed Bug 1482861 Opened 6 years ago Closed 4 years ago

Regression: unreliable popup menus since 60.0b7

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: axel.grude, Unassigned)

Details

(Keywords: regression)

All popup menus on my Add-on toolbar in QuickFolders have become unreliable between 60.0b6 and 60.0b7. It also starts failing in 60.0b7 rc from 07-Jun-2018. If I had more builds I could narrow it down further. Behavior: Sometimes the menus vanish when I drag down into them (from the button) Sometimes when dragging into to a submenu from the menu and back (the menus essentially represent folder hierarchies) the menu vanishes as well Often the commands on the menu items do nothing (both mail commands such rename folder and just clicking to go into the folder) I made some test versions on my own bug: https://www.mozdev.org/bugs/show_bug.cgi?id=26575 Thunderbird 60: QF context menus broken. I am 100% sure this is a regression, if somebody can point me to moe (windows 32bit) builds I will narrow it down further. Also not sure whether this is actually caused by changes in m-c (how do we test / compare for this) I have marked as major severity because it makes Thunderbird feel very unreliable and I fear there may be a lot more bad side FX not just affecting my Add-on. I did hg log -r THUNDERBIRD_60_0b6_RELEASE:THUNDERBIRD_60_0b7_RELEASE but nothing obvious came to mind (does it list m-c changes too?)
How to reproduce the bug: 1) Install QuickFolders Add-on 2) drag some folders that have children onto the toolbar 3) try to navigate to the child folders using click > click in submenu you should see the described behavior happen intermittently
(In reply to Axel Grude from comment #1) > How to reproduce the bug: > > 1) Install QuickFolders Add-on > 2) drag some folders that have children onto the toolbar > 3) try to navigate to the child folders using click > click in submenu I meant right-click > click any item. You can try the QuickFolders Commands > Rename Tab which should bring up a dialog for testing the missing oncommand items (but folder navigation in the main menu often also fails)
(In reply to Axel Grude from comment #2) > (In reply to Axel Grude from comment #1) > > How to reproduce the bug: > > > > 1) Install QuickFolders Add-on > > 2) drag some folders that have children onto the toolbar > > 3) try to navigate to the child folders using click > click in submenu > > I meant right-click > click any item. You can try the QuickFolders Commands > > Rename Tab which should bring up a dialog for testing the missing > oncommand items (but folder navigation in the main menu often also fails) interestingly the "click" event seems to get registered when the command is ignored, as the menu does close. Dragging the mouse into a submenu can close the whole menu as soon as the first pixel of the submenu is hit. ondrag behavior doesn't seem to be impacted negatively at all (I can still drag emails into sub-subfolders).
Keywords: regression
Priority: P3 → --
From my notes: Beta 5: hg commit -m "merge 98d536130349 (FIREFOX_60_0b14) to THUNDERBIRD_60_VERBRANCH. a=jorgk" Beta 6: No merge. Beta 7: hg commit -m "merge b93eb6ed6167 (FIREFOX_BETA_60_END) to THUNDERBIRD_60_VERBRANCH. a=jorgk DONTBUILD" So the range would be: https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=98d536130349&tochange=b93eb6ed6167 This is the merge to THUNDERBIRD_60_VERBRANCH: https://hg.mozilla.org/releases/mozilla-beta/rev/475ee126be73
(In reply to Wayne Mery (:wsmwk) from comment #4) > https://hg.mozilla.org/releases/comm-beta/pushloghtml?startdate=2018-05- > 03+19%3A17&enddate=2018-06-09+19%3A17 > https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?startdate=2018-05- > 03+19%3A17&enddate=2018-06-09+19%3A17 whoa! Sadly that's 500% wrong. Read comment #5. Date ranges do nothing. TB 60 beta was built off mozilla60, the merge on 2018-05-09 merged all of mozilla61 into beta, but we NEVER built from that - whoa!
I can't reproduce the problems on Linux with a clean TB60 and new profile.
Flags: needinfo?(acelists)
S(In reply to :aceman from comment #7) > I can't reproduce the problems on Linux with a clean TB60 and new profile. I had a couple of users (early adopters for Tb60) who reported the bug they all were on Windows.
Ignore comment #9. You need to do a full bisection on Dailies of the entire mozilla61 period: 2018-03-12 to 2018-05-07, see: https://wiki.mozilla.org/Release_Management/Calendar when mozilla60 was in beta. During that period, patches got backported to mozilla60 and finally integrated into TB 60 beta. The problem is that XUL add-ons stopped working during mozilla61 on the 29th of March. So all you can do is check the Daily of 28th. If it works there, you will have zero chance of bisecting the remaining mozilla61 period. Personally, I wouldn't spend any time looking for a regression here. Even if you find it, we will most likely not be able to fix it. I suggest to instead debug you add-on and find a workaround. Do we have function in TB like the one you have in your add-on? If so, why doesn't it fail? Can the problem be reproduced in a stripped down version of your add-on? Maybe even restartless? Then you can bisect Dailies beyond the 29th of March. Or one that works in FF? Then you could bisect on the mozilla-beta repository (https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta) if you really think that bisecting will help.
I installed the add-on from https://addons.thunderbird.net/en-GB/thunderbird/addon/quickfolders-tabbed-folders/ (version 4.10) I watched the video supplied at https://app.box.com/s/qlhxoo9f400lfdnyncdftnrwi1o21c8z (via https://www.mozdev.org/bugs/show_bug.cgi?id=26575). So the problem seems to be that people right-click on the folder button and then the popup disappears before the can move the mouse over it to select an option, right? I tried for a while and I can navigate the cascading context menu without it closing pre-maturely. However, the entire thing will close without mercy if you move the mouse off, if only for a millisecond or one pixel. Playing with it a bit more I managed to get a few cases where the context-menu of a non-selected button closed prematurely while moving from the button to the menu and vice versa. I also noticed that funny things happen with the context menu, when you hover certain menu items, like "Mark Folder Read", an icon is displayed which manages with you move the mouse off that item. That's done in code? How do we know that the code doesn't have a bug and cancel the menu altogether. So the first thing I'd try is remove the "icon show" of icons appearing and being removed. Next I'd make sure that the unusual shaped of those buttons doesn't cause a problem. There could be some rounding error, so while crossing from the button to the menu will be interpreted as moving mouse off the button and everything closes. Any, my 2 cents of wisdom ;-)
Mon Aug 13 2018 23:43:44 Warning: XUL box for menuitem element contained an inline _moz_generated_content_after child, forcing all its children to be wrapped in a block. Source file: chrome://messenger/content/messenger.xul (In reply to Jorg K (GMT+2) from comment #11) > I installed the add-on from > https://addons.thunderbird.net/en-GB/thunderbird/addon/quickfolders-tabbed- > folders/ > (version 4.10) > > I watched the video supplied at > https://app.box.com/s/qlhxoo9f400lfdnyncdftnrwi1o21c8z (via > https://www.mozdev.org/bugs/show_bug.cgi?id=26575). So the problem seems to > be that people right-click on the folder button and then the popup > disappears before the can move the mouse over it to select an option, right? Yes, that's correct I have uploaded a bunch of "more stable" versions regarding handling the onclick events at https://www.mozdev.org/bugs/show_bug.cgi?id=26575#c21 but the main problem is that child popup menus will now almost always disappear once they get touched by the mouse cursor. I think this happens specifically in Windows. (win7 pro 64 but has been reported in win10 as well) I can reproduce this in 80% of the menus, I think you can increase the chances of it happening when you have more folders turned into toolbar buttons. > > I tried for a while and I can navigate the cascading context menu without it > closing pre-maturely. However, the entire thing will close without mercy if > you move the mouse off, if only for a millisecond or one pixel. > > Playing with it a bit more I managed to get a few cases where the > context-menu of a non-selected button closed prematurely while moving from > the button to the menu and vice versa. > > I also noticed that funny things happen with the context menu, when you > hover certain menu items, like "Mark Folder Read", an icon is displayed > which manages with you move the mouse off that item. That's done in code? I don't quite understand the question - there is a mail command icon (blue folder with yellow exclamation sign) which shows on these mail commands when you hover them, which is done 100% in CSS. If that's not what you mean, can you explain it better? obviously the icons should not "leave" the menu (or drag with them) > How do we know that the code doesn't have a bug and cancel the menu > altogether. IDK, I highly recommend trying 4.11 prerelease 184 from here: https://www.mozdev.org/bugs/show_bug.cgi?id=26575#c21 It's better tested with thunderbird 60. > > So the first thing I'd try is remove the "icon show" of icons appearing and > being removed. CSS rules? ok, can do that although I do not think it has much influence on the click events. I have a bunch of drag event handlers that may be more likely to cause weird behavior. You can drag the (folder) menu items onto the toolbar (to create new shortcuts), and you can drag mails onto the folder menu items (to move mails into subfolders). > Next I'd make sure that the unusual shaped of those buttons > doesn't cause a problem. There could be some rounding error, so while > crossing from the button to the menu will be interpreted as moving mouse off > the button and everything closes. I could alleviate most of the problems of the first-level menu disappearing by adding an offset to the menu, so you won't see that one on the later pre-releases of 4.11 (pre77+). But it may well be related to same problems with popup menus for sub-subfolders. When they disappear they do it whenever the first pixel of the child menu border is hit. Crossing over quickly with the mouse can sometimes avoid the problem. thanks for looking I appreciate it! I will try the restartless mini-add-on as well, even though that's non-trivial as I have a lot of modules to refactor and the menu building code (quickfolders-interface.js) is rather vast and complex.
(In reply to Axel Grude from comment #12) > Warning: XUL box for menuitem element contained an inline >_moz_generated_content_after child, forcing all its children > to be wrapped in a block. > Source file: chrome://messenger/content/messenger.xul What's that? Comes from here: https://searchfox.org/comm-central/search?q=element+contained+an+inline&case=false&regexp=false&path= > > So the first thing I'd try is remove the "icon show" of icons appearing and > > being removed. > CSS rules? OK, my mistake, ignore that suggestion. I'll check 4.11 prerelease 184. > I have a bunch of drag event handlers that may be more likely to cause weird behavior. Yes, I know them from previous bugs and I'm worried about them :-( But here we're talking about moving a mouse to a context menu, no drag so far.
(In reply to Jorg K (GMT+2) from comment #13) > I'll check 4.11 prerelease 184. Far worse. Can you also make it better? You noticed the console errors, right? setElementStyle( .quickfolders-flat toolbarbutton:not[#QuickFoldersCurrentFolder].plastic > label, color, buttontext) An invalid or illegal string was specified ?:246 setElementStyle( .quickfolders-flat toolbarbutton:not[#QuickFoldersCurrentFolder] > label, color, buttontext) An invalid or illegal string was specified
(In reply to Jorg K (GMT+2) from comment #14) > (In reply to Jorg K (GMT+2) from comment #13) > > I'll check 4.11 prerelease 184. > Far worse. Can you also make it better? :D :D :D You're saying the menus get more "fickle" for you? Well at least that makes it reproducible. that's not what I expected. But I'll take it. X-D X-D > > You noticed the console errors, right? > setElementStyle( .quickfolders-flat > toolbarbutton:not[#QuickFoldersCurrentFolder].plastic > label, color, > buttontext) > An invalid or illegal string was specified ?:246 > setElementStyle( .quickfolders-flat > toolbarbutton:not[#QuickFoldersCurrentFolder] > label, color, buttontext) > An invalid or illegal string was specified No didn't see that one here - are you on windows, apple or linux?
try setting about:config extensions.quickfolders.debug.popupmenus.verticalOffset = -1 just to see if it's getting better again. On my system the value -3 (moving the menus up 3px) makes it better. -1 was the hard coded value before pre77.
(In reply to Axel Grude from comment #16) > try setting about:config > > extensions.quickfolders.debug.popupmenus.verticalOffset = -1 > > just to see if it's getting better again. On my system the value -3 (moving > the menus up 3px) makes it better. > > -1 was the hard coded value before pre77. Scrap that. set it to 0, restart Tb. The toolbar buttons in Thunderbird 60 apparently hate to be overlapped by the menu. It actually improved the whole situation for me a lot.
(In reply to Axel Grude from comment #15) > (In reply to Jorg K (GMT+2) from comment #14) > You're saying the menus get more "fickle" for you? Yes, menu lost in more than 50% of cases, I'd say. > No didn't see that one here - are you on windows, apple or linux? Windows 10. Using TB 60 ESR plus a few patches more. (In reply to Axel Grude from comment #17) > Scrap that. set it to 0, restart Tb. Well, the default *is* -3, with -1 you lose the menu almost every time when moving the mouse slowly. -10 doesn't help, and 0 is equally bad. I can't find a value that makes it perceivably better. V 4.10 was better than V 4.11. I'm surprised you can drive where the menu pops up. You must pop it up in code rather than relying on XUL to do it for you.
(In reply to Jorg K (GMT+2) from comment #18) > (In reply to Axel Grude from comment #15) > Well, the default *is* -3, with -1 you lose the menu almost every time when > moving the mouse slowly. -10 doesn't help, and 0 is equally bad. I can't > find a value that makes it perceivably better. V 4.10 was better than V 4.11. > > I'm surprised you can drive where the menu pops up. You must pop it up in > code rather than relying on XUL to do it for you. Yes partly because I am using modifiers for different menus (e.g. CTRL to show the folder commands submenu on the top node). What's curious is that I use the same method on the "Current Folder" Tab (center of screen) and the menus work there. if (typeof menupopup.openPopup == 'undefined') menupopup.openPopup(button,'after_start', 0, verticalOffset, isContextMenu, false, evt); else menupopup.showPopup(button, 0, verticalOffset,"context","bottomleft","topleft"); [I think openPopup was deprecated in an older version of Tb, this is in just for backwards compatibiliy]
It turned out I can fix the bug by removing em-based sizings in the toolbarbutton. Basically I wanted my paddings & heights to be depending on the (configurable) font size which leads to calculated "sub-pixel" values (such as 1.5px for padding-right, 1.5px for margin-right or 4.4px for height) - note that I am also using -moz-appearance: none to remove any OS specific stylings. For :hover I also replaced border-bottom: none with border-bottom-width: 0px. Anyway I believe that this "sub-pixelation" can lead to the menu target being "missed" when dragging which prematurely closes the menu. Fairly confident that this is caused by the new Servo engine. (Is there a switch to force using Gecko for testing?)

This is only an addons issue?

Flags: needinfo?(axel.grude)

(In reply to Wayne Mery (:wsmwk) from comment #21)

This is only an addons issue?

I believe I saw similar behavior with popup elements on the babelzilla.org website, which is basedon an old version of Joomla! on thee translation pages.

IIRC You could more or less reliably trigger the bug by zooming in on the page and then slowly dragging down on one of the menus:
https://i.imgur.com/18ENsvY.png

but I believe they fixed it since. It would be interesting to see whether they changed their CSS to use px instead of em. I believe that it shouldn't be hard to write a webpage as a test case as it is a Gecko (or whatever the rendering engine is called now) issue. I didn't do a re-test with my older QuickFolders versions to see whether it may have been fixed in the rendering engine in the meantime.

Flags: needinfo?(axel.grude)
Severity: major → normal

Axel, is this still an issue for you?

Flags: needinfo?(axel.grude)

(In reply to Wayne Mery (:wsmwk) from comment #23)

Axel, is this still an issue for you?

I don't have a test case with sub pixels right now, so I cannot confirm that it still is an issue. Shall I close this as Fixed?

Flags: needinfo?(axel.grude)

Ah, I hadn't noticed "but I believe they fixed it since."
Thanks

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.