Open Bug 317727 Opened 15 years ago Updated 2 years ago

Webpage Forces a first window overtop of a second window, including the preferences window, if "raise or lower windows" is enabled in javascript settings.

Categories

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

x86
Windows 98
enhancement

Tracking

()

UNCONFIRMED

People

(Reporter: fahlmanc_ca, Unassigned)

Details

(Whiteboard: bugday0420)

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051124 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051124 SeaMonkey/1.5a

I am using Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051124 SeaMonkey/1.5a

Visit the URL above, which is an unrelated bugzilla bug. In the initial comment on the bug there is a link to "200.176.40.9:680/rock/Isa/", click on it to open a page. 
On that page (PAGE A) there is a link to some site
with the text:
Please read our latest information and advice on Online Security

Click on that link to open a window. A new window should open, but it will remain in the background (PAGE B). If you attempt to click on that window to bring it to the foreground, it won't come to the foreground. But, from PAGE A, if you navigate to a different location, you can then bring PAGE B to the foreground. 

Also, if while on PAGE, you attempt to open the Mozilla Preferences they will also go to the background, and are not capable of being brought to the foreground while you remain at PAGE A.

Is forcing one page over another what is meant by the javascript mozilla setting that can control it (raise or lower windows)? Since it is apparently so, I suggest it the setting be more aptly named , or have a more detailed explanation of what the setting means (perhaps in a tooltip). Perhaps it could have a tooltip "allow pages to force themselves into the forground above other pages". 

In a situation where one window is forcing itself to the top is occurring, and the user doesn't want this to occur, one of the first things the user may try is to open the preferences window to attempt to change some settings. I can't image any situation where a user would then want the preferences window he just tried to open shoved permanently into the background. 

I would recommend that if a user opens a preference window, any currently opened windows or windows opening in the future not be able to force themselves above the preferences window using javascript, at least until the user clicks away from the preferences window to another opened browser window, or perhaps until the preferences window is closed.




Reproducible: Always
Version: unspecified → Trunk
> Is forcing one page over another what is meant by the javascript mozilla
> setting that can control it (raise or lower windows)?

part of it yes.

> Since it is apparently so, I suggest it the setting be more aptly named , or 
> have a more detailed explanation of what the setting means (perhaps in a 
> tooltip). Perhaps it could have a tooltip "allow pages to force themselves 
> into the forground above other pages".

With the ability to raise/lower windows, a page can just do so continually or raise it whenever you de-focus the page or whatnot and then it would appear that they have forced the window on top although that's not really what they did.  Pages don't necessarily abuse the ability that way.

The pref window is not modal, so it can be lowered below the other windows.  This is a good thing.  The correct way to deal with a page that forces itself over others is to close it (and then disable the pref if you want).
I think the preferences window should be treated in a special way in this very specific circumstance. 

It was written in comment 1: <<The pref window is not modal, so it can be lowered below the other windows. This is a good thing.>>

I was not suggesting that the pref window be made modal in all circumstances, or modal at all really. Modal has several specific components to its definition, and my suggestions only point to a "partial modality" in a very limited circumstance.
http://www.mozilla.org/projects/ui/communicator/framework/dialog_framework/ 

I want the preferences window, in opening, to be in focus and above any particular window whose javascript wishes it to be placed above all others, until I've clicked away from the preferences window (rather than having dismissed it, as is required for a modal window). After I've clicked away from the preferences window the javascript can continue doing its thing with its window, placing it above the preferences window if necessary.

The workaround solution of dismissing the window whose javascript is forcing it to the top is not ideal because a user might not want to do that just to access the preferences. That workaround involves needless loss of information. I don't, however, doubt there are other work-arounds, but I think my proposal deserves a little consideration (although I'm not capable of implementing it).



> I want the preferences window, in opening, to be in focus and above any
> particular window...

I would expect this to be always true.  When would you ever want a new window or dialog you open to be put under another (already open) window?
(In reply to comment #3)
> When would you ever want a new window
> or dialog you open to be put under another (already open) window?
> 

In general, when one appreciates javascript allowing it to occur. People may find it useful in some circumstances, or the effect wouldn't have been invented. Of course, it's easy to find abuse of the function. 
 
If one doesn't want javascript to do this to any window (let alone the specific case which is the topic of this original enhancement request), disable that controlling javascript functionality in the preferences.

If that javascript control is too coarse-grained, one could request finer-grained controls. Personally, I've not had enough trouble with javascript pages to think that mozilla's user interface controls for these functions are inadequate, but I've also had little experience.
Moving to Core::Dom:Core&HTML ("JS manipulation of windows"). Feeml free to reallocate or resolve as appropriate.
Assignee: general → nobody
Component: General → DOM: Core & HTML
Product: SeaMonkey → Core
QA Contact: general → general
Whiteboard: bugday0420
Version: Trunk → unspecified
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.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.