Location Bar address [URL] not restored after closing or switching tab

VERIFIED FIXED

Status

SeaMonkey
Tabbed Browser
VERIFIED FIXED
16 years ago
10 years ago

People

(Reporter: wkfx2003-bugzilla, Assigned: jag (Peter Annema))

Tracking

({testcase})

Trunk
testcase

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6+)
Gecko/20011118
BuildID:    2001111808

Reproducible: Always
Steps to Reproduce:
1. Go to any URL1
2. Press Ctrl-T, go to another URL2
3. Close the tab

Actual Results:  The location bar show URL2

Expected Results:  The location bar show URL1
tabbed browser
Assignee: pchen → hyatt
Component: XP Apps → Tabbed Browser

Comment 2

16 years ago
worksforme
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 3

16 years ago
Can you try more? Ok, it might be "not always" and for a fresh new window
(Ctrl-N), it does not happen but I can reproduce it quite easily.
More detail steps are:
1. Ctrl-N
2. Click on a bookmark (URL1)
3. Ctrl-T, location bar is empty
4. Switch back to URL1 tab
5. Switch back to the tab, location bar show about:blank
6. Close about:blank tab
7. the location bar still show "about:blank" while the window is displaying URL1.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
(Reporter)

Comment 4

16 years ago
Or, when in new tab, type something in the location bar, then close the tab.
(Reporter)

Comment 5

16 years ago
Try the URL and new tab.
i cannot repro this using 2001.11.28.06-comm bits on winnt.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → WORKSFORME
mass verification of WorksForMe bugs: to find all bugspam pertaining to this,
set your search string to "IfItWorksForSlappyTheSquirrelThenItWFM".

if you think this particular bug is *still* an open issue, please make sure of
the following before reopening:

a. that it's still a problem with ***recent trunk builds*** on the all
appropriate platform[s]

b. provide clear steps to reproduce (unless a good test case is already in the
bug report), making sure it pertains to the original problem (avoid morphing as
much as possible :)
Status: RESOLVED → VERIFIED

Comment 8

16 years ago
This should be reopened.  I was seeing this behavior now and again and finally
got so sick of its "randomness" that I figured out steps to repeat it:

1. Cause a new tab to be created with a URL that takes a while to come up.  I've
found that I can reproduce this 100% of the time using a bookmark I have for
www.accuweather.com:
http://www.accuweather.com/adcbin/local_index?thisZip=14068&btnZip=Go&nav=home

2.  When the accuweather tab opens, close it with a middle-click AFTER the
location bar is updated AND the tab title text has been drawn but BEFORE the
page is rendered.  It doesn't matter if this tab was opened in foreground or
background.

3.  Switch back to any other tab and notice the wrong URL in the location bar. 
Interestingly, if the accuweather tab was not foreground when closed, the
current foreground tab's URL will persist in the location bar, otherwise, the
accuweather tab URL persists.

After this, anything typed in the location bar will persist, regardless of the
foreground tab.  Also, I have seen one time that the window's title bar was
similarly stuck on the same title of the persistent URL.  Strangely, clicking
the location bar's icon to create a bookmark for the current URL will bring up
the bookmark create dialog with the correct data for the foreground tab.

Comment 9

16 years ago
This bug remains reproducible on the lastest builds.  See previous comment for
steps to reproduce.

It seems repeatable on any site where there is a susbstantial delay after the
initial connection.

Comment 10

16 years ago
I am really sorry but, I have to agree with the reporters and reopen this bug.
The accuweater.com link is, even now with mozilla RC2, still in the URL bar.
Status: VERIFIED → UNCONFIRMED
Resolution: WORKSFORME → ---

Comment 11

16 years ago
Created attachment 83817 [details]
Testcase 1

Comment 12

16 years ago
Created attachment 83818 [details]
Testcase 2

Comment 13

16 years ago
Created attachment 83823 [details]
Testcase 3

I made some testcases for this bug. as you can see. 'Testcase 1' triggers the
bug and 'Testcase 2' not, at least not on my system and 'Testcase 3' shows the
real problem.

Steps to reproduce:
1.start mozilla.
2.use ctrl-t to activate tabbed mode.
3.load 'Testcase 1'
4.select other tab

Result: frozen url bar.

Testcase 1: 
  <script language="javascript">
    window.name="content";
  </script>

Testcase 2:
  <script language="application/x-javascript">
    window.name="content";
  </script>

But the main problem here is in fact the used name "content", because that's
something special. So if I use something like this:

Testcase 3:
  <script language="javascript">
    window.name="contents";
  </script>

There is no problem at all :)

Updated

16 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

16 years ago
Keywords: nsCatFood, testcase

Comment 14

16 years ago
I've recently been seeing this simply by switching to a different tab while the
"slow" tab loads.  I tried the accuweather.com link and switched to a prior tab
while it was loading as described in the test case and now my location bar is
stuck.  Looks like it's not confined to tab closing.

Comment 15

16 years ago
changing summary to reflect last comment
Summary: Location Bar not restored after closing tab → Location Bar not restored after closing or switching tab

Comment 16

16 years ago
*** Bug 147586 has been marked as a duplicate of this bug. ***

Comment 17

16 years ago
*** Bug 145157 has been marked as a duplicate of this bug. ***

Comment 18

16 years ago
*** Bug 147891 has been marked as a duplicate of this bug. ***

Updated

16 years ago
OS: Windows 2000 → All
Summary: Location Bar not restored after closing or switching tab → Location Bar address [URL] not restored after closing or switching tab

Comment 19

16 years ago
re-assigning to jag because Hyatt is on sabbatical till mid july, afaict
Assignee: hyatt → jaggernaut

Comment 20

16 years ago
*** Bug 149792 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 21

16 years ago
Cool, I somehow completely missed this bug but came to the same conclusion based
on what I saw in bug 123672.
http://www.accuweather.com/adcbin/local_index?nav=home displays this problem and
the javascript causing it quite neatly.

I have a fix, I think.
Status: NEW → ASSIGNED
(Assignee)

Comment 22

16 years ago
*** Bug 123672 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 23

16 years ago
Created attachment 90051 [details] [diff] [review]
Don't cross chrome/content borders when trying to match a window (docshell) name against a property we're looking for

When looking for a property like "title" or "content" we'll try and find that
in the current window and sub-windows (s/window/frame/g if you prefer).
Currently a search for such a property on a xul window may end up finding a
html window or frame in a frameset with that name, not quite what we want. This
patch will prevent us from crossing the chrome/content border.
Comment on attachment 90051 [details] [diff] [review]
Don't cross chrome/content borders when trying to match a window (docshell) name against a property we're looking for

sr=jst
Attachment #90051 - Flags: superreview+
Comment on attachment 90051 [details] [diff] [review]
Don't cross chrome/content borders when trying to match a window (docshell) name against a property we're looking for

r=peterv
Attachment #90051 - Flags: review+
(Assignee)

Comment 26

16 years ago
Checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 27

16 years ago
*** Bug 149443 has been marked as a duplicate of this bug. ***
vrfy'd fixed using 2002.09.19.08 comm trunk builds. tested using the three test
cases (and about:blank/accel-T).
Status: RESOLVED → VERIFIED
Hardware: PC → All
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.