1355437 - Different behaviour on the select element for change Event across Firefox Versions

Status: NEW

(Core :: Layout: Form Controls, defect)

Description

[Miguel Queiroz]

Attachment: i02.PNG

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36

Steps to reproduce:

Please firefox, once you allow something to work, just let it that way, otherwise we programmers have to "keep" always trying to find hacks for these changes. And my clients will phone call us because their browser does not works as expected...

So much fragmentation... its a nightmare!

Okay lets go straight to the point, i have this issue on stack overflow, to test what im talking about:

http://stackoverflow.com/questions/43324130/open-file-upload-from-select-options-not-working-in-mobile

1 - Now you must click on the preview snippet
2 - click the [+] btn ( it should open options
3 - select the upload from desktop option
4 - should open a native file upload dialog




Actual results:

Firefox 52 : ok
Firefox :54 & 53 : fail.

Basically the user will select from the select html element an option. There is an event listening to the change event. When the change is the 3rd option i want it to to open a file dialog. 

On the new firefox versions beta and aurora, there will be a yellow display of a popup being blocked (see attachment) about a popup? and even if i hit allow, it wont let, there is always be counting up, on the popup block... 

Why is this? 




Expected results:

If the user clicks on the select element, there is an intent to interact with it. And all events triggered from that change event, should be allowed. 

In this case a click on the 3rd option triggers a [element].click() event on the <input type="file"/> element to open up the file dialog. ( which works on previous firefox browsers)... and i see no violation of any security here, since the user had the intent to select an option, and can cancel the dialog at anytime anyway.

It works with google chrome. Now can i trust firefox or will this behaviour change? because i lose alot of time trying to fix hacks and workaround for things that should be so simple like this?

We are a B2B application, things have to work or our clients start to call us because something stops worked because they updated the browser... and we once more have to get our hands dirty trying to find hacks...

Comment 1

[Simona Badau, Desktop QA]

I can confirm that the Open File dialog it's not opened even if you give permission to Allow pop-ups from http://stackoverflow.com. Reproduced this behavior on the latest Firefox 52.0.2 (Build ID: 20170323105023), latest Nightly 55.0a1 (Build ID: 20170413030227) and also Firefox 51.0.1.

Comment 2

[:Paolo Amadini]

Tentatively re-triaging this under "DOM: Events", in general it looks like a web compatibility issue.

Simona, do you confirm the example code works in Chrome?

Comment 3

[Simona Badau, Desktop QA]

(In reply to :Paolo Amadini from comment #2)
> Tentatively re-triaging this under "DOM: Events", in general it looks like a
> web compatibility issue.
> 
> Simona, do you confirm the example code works in Chrome?

Yes Paolo, the example provided by the reporter works in Chrome 54.0.2840.99 (64-bit).

Comment 4

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

(In reply to Simona B [:simonab ] from comment #1)
> I can confirm that the Open File dialog it's not opened even if you give
> permission to Allow pop-ups from http://stackoverflow.com. Reproduced this
> behavior on the latest Firefox 52.0.2 (Build ID: 20170323105023), latest
> Nightly 55.0a1 (Build ID: 20170413030227) and also Firefox 51.0.1.

The result is a bit different from comment 0, where Firefox 52 was working well.
I've seen some inconsistency b/w e10s and non-e10s.

Simona, could you help us get the testing results for these two modes, e10s v.s. non-e10s?

Comment 5

[Simona Badau, Desktop QA]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #4)
> (In reply to Simona B [:simonab ] from comment #1)
> > I can confirm that the Open File dialog it's not opened even if you give
> > permission to Allow pop-ups from http://stackoverflow.com. Reproduced this
> > behavior on the latest Firefox 52.0.2 (Build ID: 20170323105023), latest
> > Nightly 55.0a1 (Build ID: 20170413030227) and also Firefox 51.0.1.
> 
> The result is a bit different from comment 0, where Firefox 52 was working
> well.
> I've seen some inconsistency b/w e10s and non-e10s.
> 
> Simona, could you help us get the testing results for these two modes, e10s
> v.s. non-e10s?

Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170419030223

In e10s - after selecting the third option (Upload from your computer a file) the "Nightly prevented this site from opening a pop-up window" bar is displayed and the Upload file dialog is not opened (not even after granting permission).

In non-e10s - the behavior is different - after selecting the third option, the Upload File dialog is opened. "Nightly prevented this site from opening a pop-up window" bar is not displayed at all.

Comment 6

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

Hi Mike, you know very well about the select inconsistency b/w non-e10s and e10s, so... sorry to pin you again ;)

Comment 7

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

Can reproduce.

I think this is happening because the "change" event that we dispatch in SelectContentHelper.jsm is processed by PresShell::HandleEventInternal (which uses nsAutoPopupStatePusher to allow the popup[1]) _after_ HTMLInputElement::Init (which calls HTMLInputElement::IsPopupBlocked).

Hey felipe, do you know if there's a better way to dispatch the "change" event so that the popup state gets set to openControlled before the event is processed by the page?

[1]: http://searchfox.org/mozilla-central/rev/ae8c2e2354db652950fe0ec16983360c21857f2a/layout/base/PresShell.cpp#8128-8129

Comment 8

[:Felipe Gomes (needinfo for replies!)]

Is this the change event dispatched from the Forms:DismissedDropDown case?

Hmm offhand I don't have a good answer

Comment 9

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

Mike, given your comment, DOM:Events doesnt look a perfect component fit. Could you help us move it to the right place? Thanks.

Comment 10

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

Maybe Layout :: Form Controls? Not sure.