339 bytes, text/html
340 bytes, text/html
285 bytes, text/html
Don't cross chrome/content borders when trying to match a window (docshell) name against a property we're looking for
767 bytes, patch
|Details | Diff | Splinter Review|
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
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.
Or, when in new tab, type something in the location bar, then close the tab.
Try the URL and new tab.
i cannot repro this using 2001.11.28.06-comm bits on winnt.
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 :)
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.
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.
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.
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.
changing summary to reflect last comment
*** Bug 147586 has been marked as a duplicate of this bug. ***
*** Bug 145157 has been marked as a duplicate of this bug. ***
*** Bug 147891 has been marked as a duplicate of this bug. ***
re-assigning to jag because Hyatt is on sabbatical till mid july, afaict
*** Bug 149792 has been marked as a duplicate of this bug. ***
*** Bug 123672 has been marked as a duplicate of this bug. ***
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
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
*** 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).