Last Comment Bug 108394 - window opened by bookmarklet loses focus when bookmarklet finishes
: window opened by bookmarklet loses focus when bookmarklet finishes
Status: RESOLVED WORKSFORME
: helpwanted, regression
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: -- major with 16 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
javascript:window.open(); void 0
: 109925 151316 154939 161063 239838 (view as bug list)
Depends on:
Blocks: 88810
  Show dependency treegraph
 
Reported: 2001-11-03 23:15 PST by Jesse Ruderman
Modified: 2016-03-25 06:49 PDT (History)
18 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Jesse Ruderman 2001-11-03 23:15:52 PST
Steps to reproduce:
1. Type "javascript:window.open(); void 0" into the location bar and press 
enter.

Result: new window opens in back of current window.
Expected: new window opens in front of current window.

This breaks many of my bookmarklets (http://www.squarefree.com/bookmarklets/).
Comment 1 Tormod V 2002-01-10 03:30:36 PST
I can confirm this on MacOS 9, Mozilla 0.9.7.

Another test-case: http://www.leo.org/dict/bookmarklet_en.html
1. Drag the "Leo Dict" link to your personal toolbar
2. Make a selection of a word somewhere on the page
3. Click your new toolbar icon
Result: the new window opens behind the old

Note 1: If you mark a word, and then directly click the "Leo Dict" link on the
page, the new window correctly opens in front.
Note 2: The "Leo Dict" javascript line even includes a focus(), but that does
not seem to help.
Comment 2 neeti 2002-01-14 12:11:03 PST
Please reassign as necessary
Comment 3 Johnny Stenback (:jst, jst@mozilla.com) 2002-01-14 15:46:39 PST
Focus problem, over to bryner.
Comment 4 Jesse Ruderman 2002-01-22 20:51:22 PST
*** Bug 109925 has been marked as a duplicate of this bug. ***
Comment 5 Basil Fritts 2002-01-23 09:09:51 PST
The pseudo-URL listed for this bug works as expected in 2002012206-trunk on
Windows 98, but the following still loses focus immediately when called from the
location bar:

javascript:open('','','width=350,height=180'); void 0

Is anyone else seeing this behavior in other platform/OS combinations?
Comment 6 Pete Boyd 2002-02-07 10:17:18 PST
Mozilla 2002020703, Windows 2000.
the browser appears to do absolutely nothing when I give it
'javascript:window.open(); void 0'

but 'javascript:open('','','width=350,height=180'); void 0' atleast momentarily
creates a little window which then disappears, focus doesn't change
Comment 7 Pete Boyd 2002-02-10 02:14:19 PST
I'm really sorry. I didn't have my lameness filter on when I wrote the previous
comment. I wasn't seeing the windows being created in the background as I'm so
used to using browser tabs and was expecting them to come up as tabs. I apologise.
[Mozilla 2002020908, Windows 2000)

javascript:window.open(); void 0
opens behind current window

javascript:open('','','width=350,height=180'); void 0
opens momentarily in front of current window but quickly shifts to behind
Comment 8 Peter Trudelle 2002-03-01 15:54:16 PST
ADT triage team needs info: Is this happening on any top sites?
Comment 9 Jesse Ruderman 2002-03-01 16:19:41 PST
No, this bug only affects bookmarklets.  In fact, it only affects bookmarklets
that open new windows, and doesn't affect the more common "google search" and
"dictionary lookup" bookmarklets.
Comment 10 Basil Fritts 2002-03-01 16:39:07 PST
When I was in the habit of testing Windows builds, I never saw the problem on
any top sites. Of course, it's hard to tell, since many sites seem to want this
behavior now (e.g., pop-under ads), and I have turned off the ability to spawn
new windows with the onload event in my prefs. Very rarely do I see any sites
that want to spawn a new window with these small dimensions using JavaScript.

Unfortunately, I am not able to test Windows binaries at the present time, and I
have never seen this issue in GNU/Linux builds.

Is this behavior still exhibited in MacOS 9 builds? The platform and OS should
have been changed to all with comment #1.
Comment 11 Basil Fritts 2002-03-01 16:50:16 PST
I should hope it doesn't affect the common prompt(); bookmarklet. As it is,
window.open() losing focus is merely the Wrong Thing to do. If /prompts/ popped
behind windows, that would be Bad and Wrong. :)
Comment 12 Peter Trudelle 2002-03-07 16:34:35 PST
nsbeta1- per Nav triage team
Comment 13 Jesse Ruderman 2002-06-29 15:04:20 PDT
*** Bug 154939 has been marked as a duplicate of this bug. ***
Comment 14 Basil Fritts 2002-06-30 13:21:34 PDT
Changing Platform and OS to all, based on the most recent dupe.

Also please note, per Peter's question in Comment #8, that I would consider
Blogger (cf bug 154939) to be a top site.
Comment 15 Basil Fritts 2002-06-30 13:32:23 PDT
After considering the latest dupe to this bug, I've reset the nsbeta1- keyword
back to nsbeta1 for reconsideration by the nav triage team. See Comment #14. If
nsbeta1 was rejected for lack of any top sites, I think we've seen that now.

Also adding nsCatFood and helpwanted.
Comment 16 Samir Gehani 2002-07-18 14:33:20 PDT
Nav triage team: nsbeta1-
Comment 17 Tim Powell 2002-07-18 15:32:21 PDT
I had originally thought that this might be caused by the URL bar on the 
original window gaining focus. I tried hiding the "Navigation bar" and testing, 
but got the same results.

Looking carefully at what's happening here, it appears that focus switches back 
to the original window in order to unhighlight the bookmarklet. Here's the 
sequence of events:

Add a javascript window.open bookmarklet to the personal toolbar
Click and hold the bookmarklet
- Nothing has happened yet
Release the mouse click
- The bookmarklet is still highlighted as the new window is opening
- The new window opens and is on top for a flash
- It switches back to the original window and unhighlights the bookmarklet

Is the right way to fix this to have the bookmarklet unhighlight immediately 
and then do the bookmarklet action? Why does the original window gain focus? Is 
there still code there that forces a switch back?
Comment 18 Jesse Ruderman 2002-08-05 10:35:55 PDT
*** Bug 161063 has been marked as a duplicate of this bug. ***
Comment 19 Jesse Ruderman 2002-08-05 10:43:27 PDT
This regression might have been caused by the fix for bug 96592, "remove focus
on url-bar after loading a bookmark".
Comment 20 Jesse Ruderman 2002-08-10 13:03:02 PDT
*** Bug 151316 has been marked as a duplicate of this bug. ***
Comment 21 Jesse Ruderman 2004-04-06 23:40:49 PDT
*** Bug 239838 has been marked as a duplicate of this bug. ***
Comment 22 adam souzis 2004-07-25 12:44:05 PDT
anyone know a workaround for this? thanks.
Comment 23 Will Stufflebeam 2004-08-17 06:05:42 PDT
I don't have a solution, but I've got a Mac OS X testcase

Firefox 0.9.3 running on Mac OS X 10.2.8 exhibits this behavior. 

the following code acts exactly as described in this bug:
----
javascript:window.open(); void 0
----

But, the following code works as intended (with the new window keeping focus):
[Code for Furl bookmarklet - furl.net]
----
javascript:(function(){var%20hd=document.getElementsByTagName('head')[0];hd?
(function(){var%20s=document.createElement('script');s.setAttribute('src',
'http://www.furl.net/resources/furlItCompleteMoz.jsp');s.setAttribute('type',
'text/javascript');hd.appendChild(s);})():window.open(
'http://www.furl.net/storeIt.jsp?t='+escape(document.title)+'&u='+escape(
document.location.href)+'&c='+escape(document.getSelection?
document.getSelection():''),'myfurlwindow','scrollbars=no,width=475,
height=575,left=75,top=20,status=no,resizable=yes');})();
----

any ideas on a fix?

The unhighlighting of the bookmark/url idea is a good one, but I'm not sure,
since the above Furl.net code works without a hitch. 
Comment 24 Jesse Ruderman 2004-12-12 12:19:40 PST
Bug 232605 has a fix for the Firefox version of this bug.
Comment 25 Liviu Cirdei [:liviucirdei] 2016-03-25 06:49:13 PDT
User Agent 	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID 	20160315153207

Considering bug 232605 was fixed and I can't reproduce this issue I will close the bug as WFM. If anyone can reproduce the issue on a current build, fell free to reopen it.

Note You need to log in before you can comment on or make changes to this bug.