657145 - window.open() during mousedown event creates popunder sometimes

Status: NEW

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

Description

[Jesse]

User-Agent:       Mozilla/5.0 (Windows NT 6.0; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

It appears that Firefox is the only modern Internet browser that does not allow raising and lowering windows via JavaScript by default. More specifically, self.focus() appears to be ignored by FF when “Allow scripts to raise and lower windows” is not checked. As a professional developer, I have a good guess as to why the FF developers chose to not allow raising and lowering windows via JavaScript by default and think it may have something to do with “pop-up-spam” and if so then it’s unfortunate that those developers of “pop-up-spam” have spoiled it for the rest of us developers whom intend to use an Internet browser’s capabilities to develop applications desirable by all. My application uses windows a.k.a pop-ups as it main method of navigation. Basically, my application’s main window contains a link which calls a JavaScript function when clicked. The JS function opens a new window. The new window attempts to self.focus() from within the new window’s body onload event. All other Internet browsers including IE, Safari, Chrome, and Opera correctly bring the new window to the front using “self.focus()” while FF leaves the new window in the back unless also “Allow scripts to raise and lower windows” is checked. Furthermore, FF correctly prompts “Firefox prevented this site from opening a pop-up window” and when selecting “allow pop-ups for this site”, FF does invoke the new window but does not seem to allow the new window to invoke the “self.focus()” method unless “Allow scripts to raise and lower windows” is checked. I think that FF not allowing “self.focus()” on user approved/allowed sites is anti-intuitive and therefore should be allowed. Assuming that FF chose to not allow scripts to raise and lower windows due to “pop-up-spam” then I think a compromise can be achieved that would both thwart “pop-up-spam” while also allowing scripts to raise and lower windows by default in a limited fashion. The compromise would be that FF would allow a window to be raised only once and cannot be raised from within a delayed event such as a timer when “Allow scripts to raise and lower windows” is not checked. My tests were performed on Windows FF 4.0.1 and Windows FF 3.6.16.
 
Thank you for your consideration,

Jesse



Reproducible: Always

Steps to Reproduce:
Clearly explained @
http://www.bradnersmith.com/dev/bugFFpopupFocus.asp


Actual Results:  
New window appears in the back and not focused.

Expected Results:  
New window should appear in the front and focused.

Website developers desire consistency among Internet browsers and in the absence of consistency, Website developers tend to develop for the least common denominator and in this case it’s Firefox. I hope that FF realizes they are alone among Internet browsers in not supporting “self.focus()” in the same way that all other Internet browser vendors have and therefore reconsider doing so. Workarounds are appreciated provided they do not include the obvious which is the change each FF using my application to “Allow scripts to raise and lower windows” to checked.

Thank you in advance for your consideration,

Jesse

Comment 1

[Mounir Lamouri (:mounir)]

Jesse, if I understand correctly, you are doing this:
w = window.open(...);
and w focus itself.

Can you try this instead:
w = window.open(...);
w.focus();

Comment 2

[Jesse]

(In reply to comment #1)
> Jesse, if I understand correctly, you are doing this:
> w = window.open(...);
> and w focus itself.
> 
> Can you try this instead:
> w = window.open(...);
> w.focus();

Hi Mounir,

Thank you for your quick response and suggested workaround which is very much appreciated. I’ve updated http://www.bradnersmith.com/dev/bugFFpopupFocus.asp with your suggestion. It demonstrates that your suggestion did not work. In other words, the new window continues to appear in the back when FF “allow scripts to raise and lower windows” is not checked. The intent is that the new window appear in the front and focused.

Just one more suggestion to the FF developers:
It appears that any attempt to focus on a window is ignored when “allow scripts to raise and lower windows” is not checked. It seems that no other Internet browser has this setting and even if it does, it’s not the default. FF is alone with this feature and making it a bit of a pain for developers. If FF is going to ignore JS instruction like “self.focus()” then FF should at the very least add a console message like “warning: self.focus() ignored at line #30 @ your.js” due to FF user setting “allow scripts to raise and lower windows”. The console message would save developers plenty of time attempting to determine why their script works on all other Internet browsers while not working on FF.  

Thanks again for your consideration,

Jesse

Comment 3

[Jesse]

Mounier’s suggested workaround above did not work. Comments from Firefox are appreciated?

Thank you in advance,
Jesse

Comment 4

[Mounir Lamouri (:mounir)]

Actually, your popup should be focused when raised. There is no reason to have it in the background. You should probably try this on another profile, see http://support.mozilla.com/en-US/kb/Managing+profiles

I tried this locally and it seems to work as expected.

Comment 5

[Jesse]

(In reply to comment #4)
> Actually, your popup should be focused when raised. There is no reason to
> have it in the background. You should probably try this on another profile,
> see http://support.mozilla.com/en-US/kb/Managing+profiles
> 
> I tried this locally and it seems to work as expected.

Mounir,
I would consider submitting an incident here only after already confirming the problem on several FF profiles, FF versions, and different computers. In other words, your suggestion to use another profile was confirmed to not work prior to submitting this incident and just to be sure – I testing it once again just now and did not work. You indicated that you tried locally and worked for you which is wonderful but you did not share any sample code. Did you try the link I provided with this incident? The link below proves my case which is that FF is not in-line with any other Internet browser due to FF being the only Internet browser having the setting “Allow scripts to raise and lower windows” together with this setting not checked as the default. The FF developers should consider allowing scripts to raise and lower windows for sites listed as approved according to the FF “blocked pop-up windows exceptions” which would bring FF much closer to being equal to other browsers.
 
Use FF (any version) with default settings including “Allow scripts to raise and lower windows” not checked. 
http://www.bradnersmith.com/dev/bugFFpopupFocus.asp.

Thanks again for your time and consideration,

Jesse

Comment 6

[Mounir Lamouri (:mounir)]

Attachment: Working testcase

Can you tell me how your example differs from that? This is working correctly (ie. the popup is shown in front). You shouldn't have to call ".focus()".

It would be really appreciated to reduce your test case to a simple HTML file so we can found if that's a bug in Firefox or in your code. Though, I would tend to say that it might be your code if you had to call .focus().

Comment 7

[Jesse]

(In reply to comment #6)
> Created attachment 534711 [details]
> Working testcase
> 
> Can you tell me how your example differs from that? This is working
> correctly (ie. the popup is shown in front). You shouldn't have to call
> ".focus()".
> 
> It would be really appreciated to reduce your test case to a simple HTML
> file so we can found if that's a bug in Firefox or in your code. Though, I
> would tend to say that it might be your code if you had to call .focus().

Mounir,
Your sample code differs from mine is that your code uses a <button> and the button’s onclick event to open a new window which I agree works correctly. My sample code uses an <a> and the onmousedown event to open a new window. It’s desirable to use the onmousedown event vs. onclick because onmousedown is actually faster than onclick due to onclick event firing when the mouse button is released while onmousedown fires when the mouse button is pressed without having to wait for the button to be released. The performance gained by using the onmousedown event vs. onclick is very noticeable for users whom tend to hold the mouse down longer than necessary but still measurable for those that click quickly. Again, my case is that my code is treated differently on only one Internet browser. It seems that a possible workaround would be to use the onclick event which appears to not suffer the problem where the new window is not in front and not focused but degrades performance due to the aforementioned and therefore not really a desirable solution. Please advise.


Mounir’s sample code updated to show the problem described by this case at the URL below.
http://www.bradnersmith.com/dev/bugFFpopUp.html

Thanks again for your time and consideration,

Jesse

Comment 8

[Jesse]

Mounir,

I believe I’ve stated my case clearly which demonstrates how FF using default settings interprets JS differently compared to all other browsers when using a <button>’s onmousedown event which results in a new window not appearing in the front and focused. There does not appear to be an acceptable workaround and therefore should warrant FF’s consideration to correct the problem or at least an acceptable response as to why the problem will not be corrected.

Visit the following URL for more information and example of this FF bug. 
http://www.bradnersmith.com/dev/bugFFpopUp.html

Thanks again for your time and consideration.

Jesse

Comment 9

[Mounir Lamouri (:mounir)]

Thanks for your test case, it's really interesting: it seems that we are facing a race condition when we call window.open() from a mousedown event. Most of the times, it seems to create a popunder on a release build (the ones from mozilla.org) but on a debug build (built myself), it never creates a popunder but a regular popup.

It's not a major issue considering that creating a window from a mousedown event isn't allowed and most websites will not do that. Though, it would be interesting to know why this is happening.

Comment 10

[Mounir Lamouri (:mounir)]

As usual for popup stuff, it's working well on GNU/Linux with GTK (at least for me) but not on Windows and MacOS X.

Comment 11

[Mounir Lamouri (:mounir)]

I had another look and I think the following happens: when you click on the link with the mousedown event handler, the popup is opened. But, we also give focus to windows on the mousedown event. Thus, if you are still pressing the mouse button when the popup gets the focus, the main window gets the focus back. If your computer is fast enough, the popup loading should be more or less instantaneous that is why the issue seems to appear all the time and seems to never appear with debug builds. Though, you can reproduce that very easily on a debug build by holding the mouse button long enough.

This is still working with GTK.

I don't know the involved code enough to have a clear idea on how we could fix that. Though, I wonder why we give the focus to a window way after pressing the mouse button. Is the platform sending events all the time while the button is pressed?

Comment 12

[Mounir Lamouri (:mounir)]

Boris, by any chance, do you have any idea what could create this situation (see comment 11)?

Comment 13

[Boris Zbarsky [:bzbarsky]]

Nope, not offhand.  Maybe Neil knows?

Comment 14

[Neil Deakin]

We don't give focus to windows on mousedown. The platform handles that for us. Is this an issue with specific platforms?

Comment 15

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.

Comment 16

[Jeremy Jewkes]

Attachment: same problem

Thanks from cbadrusttichows1978.