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

Status: NEW

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

Description

[jayjayjazz]

Attachment: firefoxMouseoverFails.html

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.

Comment 1

[jayjayjazz]

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.

Comment 2

[Fahima Zulfath]

[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?

Comment 3

[Cosmin Muntean [:cmuntean], Ecosystem QA]

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?

Comment 4

[Rex]

@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.

Comment 5

[jayjayjazz]

Please see the comment from Rex! He explained the bug in further detail.

Comment 6

[Hsin-Yi Tsai (she/her) [:hsinyi]]

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!

Comment 7

[Cosmin Muntean [:cmuntean], Ecosystem QA]

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?

Comment 8

[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.

Comment 10

[Ben Tian (inactive)]

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]<

Comment 11

[Ben Tian (inactive)]

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

Comment 12

[Ben Tian (inactive)]

|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

Comment 13

[Ben Tian (inactive)]

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()

Comment 14

[Ben Tian (inactive)]

As a reference, the CSS overflow spec allows scroll container for 'hidden'.
https://www.w3.org/TR/css-overflow-3/#valdef-overflow-hidden

Comment 15

[Ben Tian (inactive)]

(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.

Comment 16

[Ben Tian (inactive)]

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

Comment 17

[Ben Tian (inactive)]

(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

Comment 18

[Ben Tian (inactive)]

(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.

Comment 19

[Ben Tian (inactive)]

(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

Comment 20

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 21

[jayjayjazz]

Hi hsinyi,

since 4 years no update. Anything planned for this bug report?

Comment 22

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to jayjayjazz from comment #21)

Hi hsinyi,

since 4 years no update. Anything planned for this bug report?

Dear jayjayjazz, thank you for reporting this issue and coming back. We have been working on issues with higher priority or severity. If there is new information that we should consider to bump the priority here, such as broken sites or blocking scenarios without workarounds, etc., please don't hesitate to let us know that we will be happy to review again. Thank you.