1365959 - [e10s] changing selectbox in iframe makes content in outer frame unclickable

Status: RESOLVED DUPLICATE of bug 1351072

(Core :: Layout: Form Controls, defect, P2)

Description

[micha.hastrich]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Steps to reproduce:

For a simplified version you need a html page with a button and an iframe. In the iframe you need a <select>. If you change the value of the select it is not possible to click in the outside frame. You need to do two clicks - the first one actives the outer frame an the second click aktivates the onclick action.

I will provide an example as an attachment.


Actual results:

The Button in the outer Frame was not clickable - it didn't even render the "cursor:pointer" which it has in its CSS. Onclick action is not performaed on click. After clicking the button or clicking anywhere else in the outer frame everything is back to normal - you get the pointer and the onclick action is performed.

After cleaning up firefox it works again.
We tried this on different OS and workstations (Win7, Win10, MacOS) and we were able to reproduce it on every system.


Expected results:

After selecting a new value in the selectbox the cursor:pointer over the button in the outer frame should have been rendered and it should have been possible to click the button and activate its onclick action.

Comment 1

[micha.hastrich]

Attachment: firefoxbug.html

Comment 2

[micha.hastrich]

Attachment: iframe.html

Comment 3

[Loic]

Attachment: firefoxbug.html

Comment 4

[Loic]

Another bug with e10s and <select>.

Comment 5

[Loic]

That said, it works in FF55, so I'd say it has been already fixed.

Comment 6

[Loic]

Sorry, it's not fixed in FF55.

Comment 7

[Loic]

Regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a925f48bcc829d19b1c9f35d15c5a5f03b23b91c&tochange=32bde324c727a46b0409bc174ec33ca2d77bdc1a

It could be:
Neil Deakin — Bug 1314647, clear active state of select on mouseup, r=mconley

As Neil is not available, could you find someone able to work on this recent regression, please.

Comment 8

[Gerry Chang [:gchang]]

Track 54+/55+ as regression.

Comment 9

[Mike Conley (:mconley) (:⚙️)]

I'm really swamped with Quantum Flow and Photon stuff. overholt, we were talking about finding someone to take these <select> bugs... did you have someone in mind?

Comment 10

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late for 53.

Comment 11

[Andrew Overholt [:overholt]]

(In reply to Mike Conley (:mconley) from comment #9)
> I'm really swamped with Quantum Flow and Photon stuff. overholt, we were
> talking about finding someone to take these <select> bugs... did you have
> someone in mind?

I took this to email.

Comment 12

[Astley Chen (inactive)]

Firefox seems the only browser with this issue.
HsinYi, it's likely an issue about form state control, would you like to assign someone to pick it up?

Comment 13

[Gerry Chang [:gchang]]

Too late for 54. Mark 54 won't fix.

Comment 14

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

(In reply to Astley Chen [:astley] (UTC+8) from comment #12)
> Firefox seems the only browser with this issue.
> HsinYi, it's likely an issue about form state control, would you like to
> assign someone to pick it up?

Sure! Ben, please help this :)

Comment 15

[Astley Chen (inactive)]

Likely a dupe of bug 1351072.
Let's see if the patch in bug 1351072 could fix this issue or not.

Comment 16

[Astley Chen (inactive)]

By applying the patch in bug 1351072. the symptom in this bug is fixed.
Let's keep it up in bug 1351072 and close this one.

Comment 17

[Ben Tian (inactive)]

Thanks Astley:) Clear my ni?

Comment 18

[Liz Henry (:lizzard) (relman/hg->git project)]

Fixed in 55 in bug 1351072.