Open Bug 1352061 Opened 4 years ago Updated 2 years ago

mouseover-event not fired if "overflow: hidden;" is applied and mouse button is pressed

Categories

(Core :: DOM: Events, defect, P3)

52 Branch
defect

Tracking

()

People

(Reporter: jayjayjazz, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: parity-chrome, parity-edge, regressionwindow-wanted)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170323105023

Steps to reproduce:

Check the attached sample webpage:
Please open the console and click one of the fields and keep the mouse pressed while you move your mouse across the other fields.


Actual results:

Mouseover-event not fired if applied to div:
In this example the CSS style "overflow: hidden;" is applied to the div.

<td>
    <div style="overflow: hidden;" onmouseover="console.log('mouseover');" onmousedown="console.log('mouse button pressed');"></div>
</td>

Firefox version 52 is not firing the mouseover-event while the mouse button is pressed.
Side note: the mouseover-events are fired correctly if the mouse click was done outside of the table.


Expected results:

The mouseover events should be fired like they did in older versions.
Chrome, chromium and Internet Explorer are firing the events correctly.
Currently, there is one workaround possible:

Mouseover-event fired correctly if applied to parent element:
In this example the CSS style "overflow: hidden;" is applied to the td of the table.

<td style="overflow: hidden;">
    <div onmouseover="console.log('mouseover');" onmousedown="console.log('mouse button pressed');"></div>
</td>

Now also Firefox version 52.0.2 is firing the mouseover-event correctly while the mouse button is pressed.
[Tracking Requested - why for this release]:

[bugday-20170403]
Need more info to reproduce this issue like console page.
Does this issue happens in safe mode of the updated version of Firefox?
Status: UNCONFIRMED → NEW
Ever confirmed: true
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Firefox: 52.0.2, Build ID: 20170323105023

I have opened the provided test case in the latest Firefox release (52.0.2). Here is what I have observed:
1. For the first table:
- When I hover the boxes, I get only one "mouseover" event in the console for the first hovered box. When I click a box from the table, a "mouse button pressed" event is displayed in the console. While the mouse is pressed, when I hover the rest of the boxes, no event is displayed in the console.

2. For the second table:
- When I hover the boxes, I get only one "mouseover" event in the console for the first hovered box. When I click a box from the table, a "mouse button pressed" event is displayed in the console. While the mouse is pressed, when I hover the rest of the boxes, I get only one "mouseover" event in console for the first hovered box.

On the latest Nightly (55.0a1, Build ID: 20170403030207) build a different behavior can be observed:
1.For the first table:
- When I hover the boxes, I get a "mouseover" event in the console for for each hovered box. When I click a box from the table, a "mouse button pressed" event is displayed. While the mouse is pressed when I hover the rest of the boxes, no event is displayed in the console.

2. For the second table:
- The difference between the first table is that while the mouse is pressed when I hover the rest the boxes, a "mouseover" event is displayed in the console for each hovered box.
This behavior can be observed in Chrome and IE for both tables.

@jayjayjazz, from what I understand this should be also the expected results for the first table on Firefox?
Component: Untriaged → Event Handling
Flags: needinfo?(jayjayjazz)
Product: Firefox → Core
@Fahima: Yes, this also happens in safe mode.

--- Tested with 52.0.2 ---

1. table:
You move your mouse to any box ("mouseover" appears for each box) and click on one of them ("mouse button pressed" appears once) and keep pressing the mouse button (like for drag and drop). Now, with mouse button pressed, you move the mouse across the other boxes of the table. There is no "mouseover" apearing any more. This is wrong. You should get "mouseover" for each box like before pressing the mouse button.

2. table (the workaround):
Here you will get "mouseover" for each box while the mouse button is pressed. This is how it should be.

So both tables should behave the same.
Please see the comment from Rex! He explained the bug in further detail.
Flags: needinfo?(jayjayjazz)
According to the sentence "The mouseover events should be fired like they did in older versions." on comment 0, this sounds a regression... 
:CosMinMCG, would you be able to help find the regression window for this bug? Thanks!
Flags: needinfo?(cosmin.muntean)
Component: Event Handling → DOM: Events
Whiteboard: [parity-chrome] [parity-edge]
I have tried to perform a regression, but I didn't find any good versions of Firefox where the issue is not reproducible. I was able to reproduce the issue even on Firefox 10.

@jayjayjazz Do you remember on which Firefox version the issue was not reproducible? And also, are you using a laptop or a PC?
Flags: needinfo?(cosmin.muntean) → needinfo?(jayjayjazz)
I re-tested also the versions 47, 48, 49, 50 and 51. Of course also the version 52, where I initially have seen the problem.
I currently have no version, where I could find the good case.
The thing is that Chrome (tested with 57 and 58) are using the event correctly.
Flags: needinfo?(jayjayjazz)
Priority: -- → P3
Duplicate of this bug: 620513
Compare table cell in frame trees generated between w/ and w/o "overflow:hidden" below. Table cell w/ "overflow:hidden" has extra HTMLScroll frame in frame tree.


=== w/ "overflow:hidden" ===
TableCell(td)(3)@10a3e38e8 next=10a3e3d38 {240,0,120,120} [state=0080060800000000] [content=1147492c0] [sc=10a30e570]<
 Block(td)(3)@10a3e3990 {60,60,0,0} [state=0000100008d00000] [content=1147492c0] [sc=10a30e468:-moz-cell-content]<
  line 10a3e3ce8: count=1 state=block,clean,prevmarginclean,not impacted,not wrapped,before:nobr,after:nobr[0x108] {0,0,0,0} <
    HTMLScroll(div)(1)@10a3e3a38 {0,0,0,0} [state=0080020000000000] [content=114749350] [sc=10a30eeb0^10a30e570^10a30dc68^10a30dd70]<
      Block(div)(1)@10a3e3c40 {0,0,0,0} [state=0000100000d00200] [content=114749350] [sc=10a3e3420:-moz-scrolled-content]<


=== w/o "overflow:hidden" ===
TableCell(td)(3)@10b18b018 next=10b18b260 {240,0,120,120} [state=0080060800000000] [content=1323c79d0] [sc=10aed7570]<
 Block(td)(3)@10b18b0c0 {60,60,0,0} [state=0000100000d00000] [content=1323c79d0] [sc=10aed7468:-moz-cell-content]<
  line 10b18b210: count=1 state=block,clean,prevmarginclean,not impacted,not wrapped,before:nobr,after:nobr[0x308] {0,0,0,0} <
    Block(div)(1)@10b18b168 {0,0,0,0} [state=0000120000100200] [content=1323c7ca0] [sc=10aed7e50^10aed7570^10aed6c68^10aed6d70]<
Mouseover event is not fired for |EventStateManager::NotifyMouseOver| method returns at [1]. Checking further on why |aContent| argument is unchanged.

[1] http://searchfox.org/mozilla-central/rev/2933592c4a01b634ab53315ce2d0e43fccb82181/dom/events/EventStateManager.cpp#4127
|aContent| remains unchanged since method |HandlePositionedEvent| [1] keeps getting initial scroll frame [2] as event frame and results in identical event content, whereas non-hidden case gets frame [3] that changes as mouse moves to another <div>.

[1] http://searchfox.org/mozilla-central/rev/b318c7dca7392bd16c0b11929f55b1be133f0b31/layout/base/PresShell.cpp#7699 
[2] http://searchfox.org/mozilla-central/rev/b318c7dca7392bd16c0b11929f55b1be133f0b31/layout/base/PresShell.cpp#7389
[3] http://searchfox.org/mozilla-central/rev/b318c7dca7392bd16c0b11929f55b1be133f0b31/layout/base/PresShell.cpp#7508
The scroll frame disappears in frame tree if [1] excludes overflow:hidden case. The mouseover event would fire but opening web console window hits assertion failure [2] with this change.

Still checking why generate scroll frame for overflow:hidden.

[1] http://searchfox.org/mozilla-central/rev/507743376d1ba753d14ab6b9305b7c6358570be8/layout/base/nsCSSFrameConstructor.cpp#4773
[2]
Assertion failure: mRawPtr != nullptr (You can't dereference a NULL RefPtr with operator->().), at /Users/bentian/Workspace/central/obj-x86_64-apple-darwin16.6.0/dist/include/mozilla/RefPtr.h:315
#01: RefPtr<nsFrameSelection>::operator->() const[/Users/bentian/Workspace/central/obj-x86_64-apple-darwin16.6.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x2207344]
#02: nsTextInputSelectionImpl::SetCaretReadOnly(bool)[/Users/bentian/Workspace/central/obj-x86_64-apple-darwin16.6.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x3a6d64a]
#03: non-virtual thunk to nsTextInputSelectionImpl::SetCaretReadOnly(bool)[/Users/bentian/Workspace/central/obj-x86_64-apple-darwin16.6.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x3a6d709]
#04: mozilla::EditorBase::Init(nsIDOMDocument*, nsIContent*, nsISelectionController*, unsigned int, nsAString const&)[/Users/bentian/Workspace/central/obj-x86_64-apple-darwin16.6.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x4b91b03]
#05: mozilla::TextEditor::Init(nsIDOMDocument*, nsIContent*, nsISelectionController*, unsigned int, nsAString const&)[/Users/bentian/Workspace/central/obj-x86_64-apple-darwin16.6.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x4c8e200]
#06: nsTextEditorState::PrepareEditor(nsAString const*)[/Users/bentian/Workspace/central/obj-x86_64-apple-darwin16.6.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x3a72067]
#07: mozilla::dom::HTMLTextAreaElement::CreateEditor()[/Users/bentian/Workspace/central/obj-x86_64-apple-darwin16.6.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x3a1d880]
#08: non-virtual thunk to mozilla::dom::HTMLTextAreaElement::CreateEditor()[/Users/bentian/Workspace/central/obj-x86_64-apple-darwin16.6.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x3a1d8ac]
#09: nsTextControlFrame::EnsureEditorInitialized()[/Users/bentian/Workspace/central/obj-x86_64-apple-darwin16.6.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x526db95]
#10: nsTextControlFrame::EditorInitializer::Run()
As a reference, the CSS overflow spec allows scroll container for 'hidden'.
https://www.w3.org/TR/css-overflow-3/#valdef-overflow-hidden
(In reply to Ben Tian [:btian] from comment #14)
> As a reference, the CSS overflow spec allows scroll container for 'hidden'.
> https://www.w3.org/TR/css-overflow-3/#valdef-overflow-hidden

Chrome and Safari also have the scroll frame to allow seeing complete text by scrolling.

We have to keep the scroll frame while firing mouseover on the right event content. Need to check for possible event path.
Removing frame assignments [1] and [2] in method |PresShell::HandleEvent| makes mouseover event fired under overflow:hidden, but hits bug 519693 for missing [1].

[1] http://searchfox.org/mozilla-central/rev/20963d7269b1b14d455f47bc0260d0653015bf84/layout/base/PresShell.cpp#7387
[2] http://searchfox.org/mozilla-central/rev/20963d7269b1b14d455f47bc0260d0653015bf84/layout/base/PresShell.cpp#7524
(In reply to Ben Tian [:btian] from comment #14)
> As a reference, the CSS overflow spec allows scroll container for 'hidden'.
> https://www.w3.org/TR/css-overflow-3/#valdef-overflow-hidden

UI events about mouseover event
https://www.w3.org/TR/uievents/#event-type-mouseover
(In reply to Ben Tian [:btian] from comment #16)
> Removing frame assignments [1] and [2] in method |PresShell::HandleEvent|
> makes mouseover event fired under overflow:hidden, but hits bug 519693 for
> missing [1].
> 
> [1]
> http://searchfox.org/mozilla-central/rev/
> 20963d7269b1b14d455f47bc0260d0653015bf84/layout/base/PresShell.cpp#7387

[1] was added by bug 503943.
(In reply to Ben Tian [:btian] from comment #16)
> Removing frame assignments [1] and [2] in method |PresShell::HandleEvent|
> makes mouseover event fired under overflow:hidden, but hits bug 519693 for
> missing [1].
> 
> [1]
> http://searchfox.org/mozilla-central/rev/
> 20963d7269b1b14d455f47bc0260d0653015bf84/layout/base/PresShell.cpp#7387
> [2]
> http://searchfox.org/mozilla-central/rev/
> 20963d7269b1b14d455f47bc0260d0653015bf84/layout/base/PresShell.cpp#7524

Without frame assignment [1], overflow:hidden case falls into [2] for the frame's content not being a descendant of capturing content [3], added by bug 516615 and discussed in bug 516615 comment 17.

[3] http://searchfox.org/mozilla-central/rev/a798ee4fc323f9387b7576dbed177859d29d09b7/layout/base/PresShell.cpp#7520
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Whiteboard: [parity-chrome] [parity-edge]
You need to log in before you can comment on or make changes to this bug.