264993 - window.open() should never cause the new window to replace the existing window

Status: RESOLVED DUPLICATE of bug 264395

(Firefox :: Tabbed Browser, defect)

Description

[Thomas Rutter]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041018 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041018 Firefox/1.0

When "Force links that open new windows to open in" is checked, and "the same
tab/window as the link" is selected, this behaviour is also being applied to
Javascript that calls window.open().

While the option works great on regular links with target="_blank", allowing the
link to be either opened in a new tab, new window, or same window, when this
preference is applied to Javascript that uses window.open() this actually
removes choice, as there's no way of "middle clicking" or "shift clicking"
around it.

Javascript applications which use window.open() typically require the existing
window to remain in place so that Javascript can be used to communicate between
the existing and new window.  This bug not only prevents that but does not offer
any workaround (other than turning the option off, but then target="_blank"
links will start opening in new windows again).

Reproducible: Always
Steps to Reproduce:
1. Set "Force links that open new windows to open in" to true
2. Select "the same tab/window as the link"
3. Go to a site which relies on a Javascript window being opened which is
separate to the existing window.


Actual Results:  
Existing window is replaced with new window; there is no way of getting around
this by right-clicking or middle-clicking, etc

Expected Results:  
Open a new window

Comment 1

[Dan M]

The point behind this bug seems to be to object to a decision made in bug 172962
and to object to a suggestion made in bug 264395 without presenting an
alternative. The former point is addressed in the original bug. (Though it's
lacking a UI. If you want to file a bug to provide a UI sometime past the
current 1.0 UI lockdown, then that would most clearly be done in a new bug.) The
latter point has been addressed in bug 264395 comment 6.

*** This bug has been marked as a duplicate of 264395 ***

Comment 2

[Thomas Rutter]

I don't really have a strong opinion or agenda about how this bug should be
fixed or even whether it should be fixed.  However, this bug was created in the
light of the fact bug #264395 has 'need hidden tabs' in the summary, whereas
this bug is similar but does not advocate a need for hidden tabs.

I'm just worried that the resolution to bug #264395 will be decided on the
grounds of 'should we fix this with hidden tabs' rather than 'should we fix
this'.  In other words, bug #264395 is an enhancement which is dependant on this
bug.