Re: popup focus() behaviour with moz, firefox, ie

Csaba Gabor wrote :
Gérard Talbot wrote:
Csaba Gabor wrote :
Alex.Svetos@xxxxxxxxx wrote:
I'm trying to get a popup to keep focus when it is re-clicked.
As you understand by now, this statement of the problem is
incorrect. Rather, you are trying to have a previously created
popup regain focus when a link or button activating it is
clicked.
...
Indeed, this is a classic case of protectionism run amok.
IE and FF both let you create a named window which they will bring to
the top, especially provided that it was some user instigated
through some user initiated action, such as clicking.
It's not that simple. A secondary window could have been brought up
legitimately; after some time, it could be reloaded with advertisement
content. Or who knows; a second click on a link could load a different
document. There are lots of possibilities, variations which a persistent
scripter could take advantage of.

I'm not quite following your scenario and objection (advantage taking
mechanism). Are you referring to:
1) Window A brings up named window B, and then A or B later reload B
(which they are entitled to do)
2) Window A brings up named window B, and then a different window C in
the same domain loads up B with new content. So at this point, is
either A, B, or C allowed to (or ought to be allowed to) do a .focus()?
3) Window A brings up named window B, and then a different window C in
a different domain loads up B with new content.
4) Something else.

It would be nice if you would clarify specific scenario(s) that you
have an issue with that the popup blocker does not protect against (ie.
how could a persistent scripter take advantage?).


I was thinking of scenario 2 where document loaded in window A can focus() document #3 in window B after being loaded.

To be clear, this is not a case of a window/app trying to
raise itself to the top.
A setTimeout can do that though.
Some people create a modal window with
<body onblur="self.focus();">
you see.

I like this because it's a specific instance that we can discuss.
Woudn't it make sense to have window/self.focus() labor under the same
restrictions as window.open? In other words, it has to be initiated by
a physical user event within a certain time limit to have any effect.


Yes, it would make sense to have focus() work under the same restrictions as window.open().


To go on a bit of a digression, the kind of behaviour you have
mentioned can be achieved by an infinite loop of alerts.

Exactly. I happened to have demonstrated this in 2002 in a netscape7 newsgroup.

A solution to
this would be to have FF always allow the underlying window to be
closed (by, for example, clicking on its X button in the upper right
corner or by having a context menu for close on the right click if the
X is not visible).


An alert is a modal window; not any kind of normal secondary window. You can not reach the parent-opener without first closing the modal window. The modal window's opener can not be focused without first closing the modal window.

The main window is already at the top,
so if it wants to have a child window come to the top (which may
be viewed as part of the same (already in focus) application),
which it could do anyway with window.open, what is the problem
in allowing window.focus()?

The window is not per se the problem: its content (actual, future,
potential) is. When a browser prevents an unrequested popup, it's not so
much the window that is the problem as it is its content (advertisement,
spamming content, annoyance of being served scam ads or anything which
is not related to the reasons to visit a site in the first place).

If you visit some sites like netscape.com and yahoo.com, they are now
using DHTML layers to convey advertisement. No secondary windows
involved. But the same boring, annoying advertisement pollution.

This is off topic for this thread. I hate those kinds of ads, too.
However, opposition to popups has its basis in the fact that the user
chose to look at a website in a given window, and that window is all
the website is entitled to, except under limited circumstances (user
initiated actions). However, this argument does not apply to the
content of the web page itself. That browser window is the website's
playground and if they want to annoy users by placing ads, that's their
prerogative. That's what GreaseMonkey helps with.


It may not be that off topic. I was merely pointing out that it is unwanted polluting content that annoy us. Put it into a DHTML layer or in a window: in both cases, the users' system resources are used and abused to annoy the users.

That is to say, it makes eminent sense that if a window, B,
which was created by window A, comes to the top upon creation,
that the same window B should come to the top upon a user
initiated action leading to windowB.focus() The really silly
way around this is to close windowB and then recreate it,
There are scripts available on the web that do exactly that: as the user
reclicks the link, the script closes windowB and then recreate it entirely.

See the 9th link at
https://bugzilla.mozilla.org/attachment.cgi?id=149849&action=view

What is the id of the associated bug ... How do I use the search page
at
https://bugzilla.mozilla.org/query.cgi to figure out the bug associated
with a given attachment number?

Titlebar or source code were indicating
<title>Testcase for bug 151142 and other related bugs</title>

And by the way, what is the bug that you are referring to in your last
post in
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/78d28fdaac54b3c/
The link is broken.


I restructured my website recently. I will eventually remove all references to NS 7.

What does the "Raise or lower windows" setting do exactly?
http://www.gtalbot.org/FirefoxSection/Popup/PopupAndFirefox.html#RaiseLowerSetting


Anyway, I am not fond of this idea of killing windows one is going to
reuse just to get them to the top.


I certainly do not either: it's really a bad idea, abusing the users' system resources.


which
only serves to drive up internet traffic.

This problem and two ways of dealing with it on FF are described at
https://bugzilla.mozilla.org/show_bug.cgi?id=318535
If you agree with the assessment, I suggest voting for the bug
to give it more visibility.

The bug hasn't even been confirmed yet!

What is your point?


My first point is that this bugreport is not well done and second point it's not the correct bugreport to vote for if you want "Raise or lower windows" to default to true, to have the default to allow scripts to Raise or lower windows.

And the bug is about respecting and maintaining user settings when
upgrading Fx.

That is half the bug. But it is also about allowing window.focus() to
focus a window that the caller has rights to.

A bugreport should always about 1 single issue per bug. And it should be terse, clear and as clean as possible. In other words, no rant, no long lecture. Bugzilla is not a newsgroup discussion forum, a place for advocacy or debates, actually. It's only a place to report, investigate, then confirm, test patches, fix bugs.


Unfortunately, I don't know of a nice workaround (other than the
brute force method in the bug report) for my IE 6 on Win XP Pro.
How about simply not using window.open() if your content is important
for the users to read, otherwise warn accordingly users about a
secondary window and do not rely too much on such window.open() +
window.focus() call.

I have a web app for rapid development/prototyping. You put the input
source material into a textbox in one window, press alt+s and up pops
the result in the second window. For this type of scenario it makes
sense for the content to be delivered to a second window and for the
second window to remain where it is and for the second window to rise
to the top. Any kind of per instance warning is not a solution.

The user could always allow scripts to raise or lower windows (by the
way, would you happen to know the corresponding pref.js setting?),


dom.disable_window_flip


but
that allows access for any script. I am only suggesting that in
situations where window.open would raise a new window to the top, there
is nothing that is lost by allowing window.focus() to do the same.



Gérard
--
remove blah to email me
.

Relevant Pages

  • Re: What is wrong with WindowsXP CD?
    ... When you boot from the Windows XP setup CD, ... BIOS setup for Legacy USB devices? ... FAIL to strike any key during a few second window of opportunity, ...
    (microsoft.public.windowsxp.general)
  • Re: Need help with macro
    ... the IE that is causing a 2nd window to open or an active X is interfering ... "Walter Briscoe" wrote: ... IE.Navigate2 URL opens a second window. ... I needed to get the table starting with the string "Trading ...
    (microsoft.public.excel.programming)
  • Re: popup focus() behaviour with moz, firefox, ie
    ... IE and FF both let you create a named window which they will bring to ... have an issue with that the popup blocker does not protect against (ie. ... What is the id of the associated bug ... ... sense for the content to be delivered to a second window and for the ...
    (comp.lang.javascript)
  • Re: How do you activate the commentaries at the bottom of each page of a presentation
    ... I open them and simply type in English over the French ... but only one window at a time ... Then you could go to the Notes master, type some text in the footer ... Some of them have a 'second window' at the bottom of each page. ...
    (microsoft.public.powerpoint)
  • Re: Cant open second IE window
    ... Still could not open second window. ... first window closes and the second window opens. ...
    (microsoft.public.windows.inetexplorer.ie6.browser)