Open
Bug 1470154
Opened 5 years ago
Updated 8 months ago
theGuardian.com - menu Close click goes trough To scrollbar under it
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Core
DOM: UI Events & Focus Handling
Tracking
()
NEW
People
(Reporter: cfogel, Unassigned)
Details
(Keywords: regression)
Attachments
(1 file)
1.46 MB,
image/gif
|
Details |
[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;
Reporter | ||
Comment 1•5 years ago
|
||
- 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.
status-firefox60:
--- → affected
status-firefox61:
--- → affected
status-firefox-esr52:
--- → affected
status-firefox-esr60:
--- → affected
Updated•5 years ago
|
Keywords: regression
Updated•5 years ago
|
Comment 2•5 years ago
|
||
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
Comment 3•5 years ago
|
||
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
Comment 4•5 years ago
|
||
Good questions, Pascal! I'll let Hsin-Yi make that call :)
Flags: needinfo?(overholt) → needinfo?(htsai)
Comment 5•5 years ago
|
||
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
Flags: needinfo?(htsai)
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.
Assignee | ||
Updated•4 years ago
|
Component: Event Handling → User events and focus handling
Updated•8 months ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•