Problem is on Trunk Builds If you click on this link http://wiki.http//wiki.mozilla.org/Performance/Status_Meetings/2007-July-18 in Thunderbird it opens a new Tab in Firefox that is greyed out and not usable. You can`t also use this tab for other urls. On Firefox 188.8.131.52 it displays only the "Can`t find page" Net Error and the Tab is usable. Regression between 2007-06-14 and 2007-06-15 (thanks martijn) http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-06-14+04&maxdate=2007-06-15+09&cvsroot=%2Fcvsroot So we think its a regression from Bug 371360
This might help diagnose the problem -- Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20070509 SeaMonkey/1.1.2 with WindowsXP. Preference set to open link from external application in a new window. After attempting and failing to open bad URL, I went to the address area and removed the "//wiki.http". On selecting Enter, I got the desired Web page. Thus, either the problem is limited to Firefox and is not in SeaMonkey, or else the problem is limited to configurations in which links from external applications open new tabs instead of new windows (or both).
OS: Windows Server 2003 → All
Priority: -- → P1
Hardware: PC → All
Summary: Broken link opening from thunderbird causing ghost tab → [FIX]Broken link opening from thunderbird causing ghost tab
Target Milestone: --- → mozilla1.9beta1
Just a note, I just saw this with a page that took a long time to respond, when I hit stop before it loaded or timed out. > The issue is that for external loads we CreateAboutBlankContentViewer before > doing the load... which fires the unload event right then and there. If the > load then fails in any way, we'll never be able to make use of this docshell > again. I guess that means this case is already covered by the patch?
> Just a note, I just saw this with a page that took a long time to respond Loaded from outside the app?
(In reply to comment #5) > Loaded from outside the app? Yes.
Then yeah, this patch should help.
Attachment #273049 - Flags: superreview?(jst) → superreview+
Marking blocker to make sure we get this in.
Flags: blocking1.9? → blocking1.9+
Duplicate of this bug: 390319
Comment on attachment 273049 [details] [diff] [review] Fixed it seems really fragile to maintain this as state on the docshell instead of the document or something
Attachment #273049 - Flags: review?(cbiesinger) → review+
Comment on attachment 273049 [details] [diff] [review] Fixed Yeah, true. I was going for minimally invasive here....
Comment on attachment 273049 [details] [diff] [review] Fixed Need this on branches too if bug 371360 lands there.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
it'd also be nice if the header had a comment about the purpose of this variable
Checked one in.
Comment on attachment 273049 [details] [diff] [review] Fixed approved for 220.127.116.11 and 18.104.22.168, a=dveditz for release-drivers
verified fixed 22.214.171.124 using Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:126.96.36.199pre) Gecko/20070929 BonEcho/188.8.131.52pre ID:2007092904 following my steps to reproduce Also verified fixed for Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a9pre) Gecko/2007092705 Minefield/3.0a9pre ID:2007092705 -> adding verified keyword and changing Bug status to verified
You need to log in before you can comment on or make changes to this bug.