Closed Bug 121377 Opened 18 years ago Closed 14 years ago

When using "Force links.. new tab", tabs from targeted links and window.open forget their name (tabs not reused when they should be)

Categories

(SeaMonkey :: Tabbed Browser, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.0a1

People

(Reporter: mozbug, Assigned: bzbarsky)

References

(Depends on 1 open bug)

Details

(Keywords: testcase, verified1.8.1, Whiteboard: [window targeting])

Attachments

(1 file)

5 hours-old CVS linux
20020122xx win98
2002012103 macos9

Open attached testcase.

All the links have a target="thisisanewwindow" and thus, will open in the same
window when clicked.

Click on one link : a new window appears and link is loaded.
Open a new tab within the new window.
Go back to first window.
Click on a link.

Expected result: link is loaded in first tab of second window.

Actual result: another new window is opened.
Attached file testcase
-> future, helpwanted
Keywords: helpwanted
Target Milestone: --- → Future
QA Contact: sairuh → pmac
Blocks: 218399
*** Bug 218399 has been marked as a duplicate of this bug. ***
Depends on: 277972
Blocks: 161466
*** Bug 297670 has been marked as a duplicate of this bug. ***
*** Bug 304924 has been marked as a duplicate of this bug. ***
Is this fixable in the beta2 cycle, with regards to the new integrated tab code
from bug 172962?
Nominating for blocking, because with the new UI in Firefox to redirect new
window calls to a new tab, anyone setting this will see a lot of sites break.
Flags: blocking1.8b5?
Keywords: testcase
no patch, not a regression over 1.0 and not serious enough for us to stop the
release. Hopefully someone will work on this for the next release. 
Flags: blocking1.8b5? → blocking1.8b5-
Blocks: 210986
Whiteboard: [window targeting]
*** Bug 314402 has been marked as a duplicate of this bug. ***
Summary: windows with tabs forget the target name → When using "Force links.. new tab", tabs from targeted links and window.open forget their name (tabs not reused when they should be)
Flags: blocking-aviary2?
We need to find a way to fix this, as discussed a number of times.  Not sure who's getting this hot potato, but I'm pretty sure its not jag.
Assignee: jag → nobody
Flags: blocking-aviary2? → blocking1.8.1+
QA Contact: pmac → tabbed-browser
*** Bug 325571 has been marked as a duplicate of this bug. ***
Depends on: 326009
Fixed by checkin for bug 326009
Assignee: nobody → bzbarsky
Keywords: helpwanted
Target Milestone: Future → mozilla1.9alpha
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
This is a similar circumstance, but I can't find a bug for it; which is still not working in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060326 Firefox/1.5.0.2 ID:2006032605


http://www.loyalistarms.freeservers.com/blunderbussprivatecontractstyle.html

here is the code:
<p align="center"><a href="javascript:;" onClick="MM_openBrWindow('blunderbussprivatecontractstyle-a.jpg','blunderbussprivatecontractstyle','scrollbars=yes,resizable=yes')"><img src="blunderbussprivatecontractstyle-a.jpg" width="416" height="117" border="0"></a><br>
    <font face="Times New Roman, Times, serif" size="3"><i>(click to enlarge)</i></font></p>

  <p align="center"><font face="Times New Roman, Times, serif" size="3"><a href="javascript:;" onClick="MM_openBrWindow('blunderbussprivatecontractstyle-b.jpg','blunderbussprivatecontractstyle','scrollbars=yes,resizable=yes')"><img src="blunderbussprivatecontractstyle-b.jpg" width="324" height="138" border="0"></a><br>
    <i>(click to enlarge)</i><br>
Could you mark this fixed1.8.1 if it was fixed on the 1.8 branch by the branch checkin of bug 326009?
Keywords: fixed1.8.1
(In reply to comment #13)
> This is a similar circumstance, but I can't find a bug for it; which is still
> not working in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2)
> Gecko/20060326 Firefox/1.5.0.2 ID:2006032605
> 
> 
> http://www.loyalistarms.freeservers.com/blunderbussprivatecontractstyle.html

Not sure what bug this is, but center clicking this link opens a blank tab and the link in a new window, not a new tab. This indicates to me it is also present on the 1.8.0.x branch, and is not completely fixed.
There are no plans to fix this on the 1.8.0.x branch.
Verified with Windows and Mac 2.0b1rc3 builds
Status: RESOLVED → VERIFIED
For what it's worth... this needs to be separately verified on trunk, since the changes were somewhat different.  Reopening so I can put it back in a "RESOLVED FIXED" state...
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
The testcase still fails in Firefox 2 if you open a new tab. If you click on a link on the testcase to open a new named tab, then create a new tab using File | New Tab, then go back to the testcase and click on another link, the link is opened in a new tab instead of the previously opened tab. Should this bug be reopened, or should I file a new bug report?
Steve, good catch!  I've filed bug 360579 on this because that way we can better track what got fixed on the branch at what points.  Fix should be up in a minute.
The testcase fails if you update Firefox and restore the session. If you click on a link on the testcase to open a new named tab, then update Firefox using Help | Check for Updates... and restore the session, then go back to the testcase and click on another link, the link is opened in a new tab instead of the previously opened tab. Should this bug be reopened, or should I file a new bug report?

I reproduced with updating from the October 3 trunk build of Firefox to Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007100605 Minefield/3.0a9pre
Steve, it looks like session restore simply doesn't save/restore window names.  given that, there's no way this testcase can work across a session restore.

You want to file new bug, on the session restore code.
Flags: in-testsuite?
Someone's already filed bug 403179 on the issue.
Product: Core → SeaMonkey
Target Milestone: mozilla1.9alpha1 → seamonkey2.0a1
You need to log in before you can comment on or make changes to this bug.