Closed Bug 1326849 Opened 8 years ago Closed 7 years ago

[e10s] window.open() popup doesn't work on 'change' event (onchange) in select if user clicks on option

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID
Tracking Status
firefox50 --- affected
firefox51 --- affected
firefox52 --- affected

People

(Reporter: arni2033, Unassigned)

References

Details

>>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160526082509
STR_1:
1. Open url   data:text/html,<select onchange='window.open()'><option>1<option>2
2. Click on select dropmarker to open drop-down list of options
3. Click on the option that isn't selected

AR:  Popup is blocked
ER:  Popup should open
No longer blocks: 1277113
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Firefox 50.1.0, Build ID: 20161208153507

I have managed to reproduce this issue on the latest Firefox (50.1.0) release and latest Nightly (53.0a1) build.
Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core
We need check the HTML spec with regards to this being allowed to open a pop-up. I think the heuristics of the popup blocker might be kicking in and deliberately blocking this (which makes sense, IMO). 

Chrome also blocks the pop up. Safari also blocks the popup.
Ok, so as we are moving everyone to E10s, this will fix itself once we do the full roll out, right?
Hi Mike, we also noticed that in non-e10s, a new tab is opened indeed. Though Marcos and I tend to think the current e10s behaviour makes sense, we'd like to have your confirmation about if this is invalid, since you just finished non-e10s/e10s select refactoring. Thanks!
Flags: needinfo?(mconley)
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #4)
> Hi Mike, we also noticed that in non-e10s, a new tab is opened indeed.
> Though Marcos and I tend to think the current e10s behaviour makes sense,
> we'd like to have your confirmation about if this is invalid, since you just
> finished non-e10s/e10s select refactoring. Thanks!

Yeah, I think this behaviour is probably better (blocking the popup by default). Bug 1331725 should fix this for non-e10s when we enable the same mechanism for that configuration.

So I think this is RESOLVED INVALID.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(mconley)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.