1.46 MB, image/gif
[Affected versions]: - Firefox 60.1.0esr, 61.0b9, 62.0a1 (2018-06-21) [Affected platforms]: - Win 7x32; - Ubuntu 16.04LTS; - MacOS 10.12.6 [Steps to reproduce]: 1. Launch Firefox; 2. Access https://www.theguardian.com/uk/culture 3. Click on the Restore down button(between - and x); 4. Resize the browser width @ half the screen; 5. Click on the menu button for the website (☰); 6. Adjust the browser width so that X button overlaps with the scrollbar; 7. Hover over the websites X button, until the scrollbar is highlighted as hovered over; 8. Click on the website's X button and try to drag up/down; [Expected result]: - After the click the menu is no longer displayed. [Actual result]: - The website menu is not closed, scrolling is available in the website menu section [Regression range]: - different behavior on 44.0a1, will investigate and provide a regression range asap. [Additional notes]: - attached screenshot with the issue;
- adjusted flags; - reproducible on Win10x64 as well; - using mozregression, was able only to come up with the following pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2ea3d51ba1bb9f5c3b6921c43ea63f70b4fdf5d2&tochange=e5859dfe0bcbd40f4e33f4a633f73ea3473a7849 - last good: 2016-07-30 2ea3d51ba1bb9f5c3b6921c43ea63f70b4fdf5d2 - first bad: 2016-07-31 e5859dfe0bcbd40f4e33f4a633f73ea3473a7849 - Up until this version the (x) button is not even displayed.
This is one of those regressions that happened a while ago so I'd prefer we don't track it like other regressions.
Priority: -- → P2
Andrew, given that we have shipped multiple versions with this regression and that it is an unassigned P2, could we get this bug retriaged to either lower its priority or get it assigned to somebody if we still think this should be fixed in the next releases? Thanks
Good questions, Pascal! I'll let Hsin-Yi make that call :)
Flags: needinfo?(overholt) → needinfo?(htsai)
Thanks for the question, Pascal. When I used a mouse hovering over the leave button, the hover state didn't change and there still showed a cursor rather than a pointer. I seems like something wrong with event target determination. So moving to Event handling component, hopefully it's a better fit... ... I looked into reported bugs to have some idea about the volume of this unexpected behavior. There are some incorrect event target bugs but no obvious one having a similar situation regards element overlapping. According to the age of this issue and low report volume, I am going to set this as P3 for now.
Component: DOM: Core & HTML → Event Handling
Priority: P2 → P3
Happy to take a patch in nightly; if it seems low risk enough please feel free to request uplift to 65 beta.
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.