Closed Bug 66034 Opened 24 years ago Closed 23 years ago

Content in Mozilla disappears seemingly at random [open link in new window breaks at times]

Categories

(Core Graveyard :: GFX, defect)

Product:
Core Graveyard
Component:
GFX
Platform:
All
Windows 98
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: verbal, Assigned: jag+mozilla)

References

Details

(Keywords: regression)

Attachments

(3 files)

[test] changes necessary to use iframe in viewSource.xul
1.43 KB, patch
Details | Diff | Splinter Review
patch 1
2.75 KB, patch
Details | Diff | Splinter Review
patch 1
2.75 KB, patch
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20010119 BuildID: 2001011904 Ok heres the deal. Sometimes when you have two windows of Mozilla open while browsing the net and you switch back and forth a page that displayed content before now displays just white. Reproducible: Sometimes Steps to Reproduce: 1) Browse the Web 2) Open A New Window (for me it *seemed* to happen only when i opened a link in a new window) 3) Watch it load 4) Switch back to first window browse some more and then switch back to the second window Actual Results: Instead of the page rendered, you have white. Expected Results: The correct page For me this started happening after creating a new profile on todays build. JLP had it happen on yesterdays build as well. This seems to be limited to Win32 platform but I cant say for sure. It seems to happen at random with no rime or reason to it.
Maybe I should add that when switching to the page that shouldn't be blank, the content briefly (for a very short time) apeared and then disapeared. After reloading the page it apeared correctly. Mozilla 2001011820 on Windows 2000 SP1.
you know, i can actually confirm this: win98 2001194 build. i have defualt hompage set to mozilla.org. i open a new window (ctrl n), the page loads. I switch to the original window, then back and then suddenlty i see a empty page. Highlighting makes it show though. over to layout for initial triage
Assignee: asa → clayton
Component: Browser-General → Layout
QA Contact: doronr → petersen
keywords. this used to work, regression
Keywords: mozilla0.9, nsbeta1, regression
I've seen things like this happen to bonsai query results, but in a debug build there are a bunch of layout assertions triggered whenever that happens. Does the page reappear when you resize the window? Does it reappear when you drag another window over the blank window and then drag it away?
Do you have that problem with or without cache enabled/disabled?
dbaron - yes, resizing shows the page as does moving over it with another window. this is windows specific, could not repro on linux. this also happens with and without disk cache enabled. I also changed teh default homepage to a site I never visited, same thing happened.
cc:ing kmcclusk, although I think this started before his painting changes
*** Bug 67521 has been marked as a duplicate of this bug. ***
*** Bug 67215 has been marked as a duplicate of this bug. ***
Moving to Comp. as per Asa recommendation.
Component: Layout → Compositor
Reassigning to default owner.
Assignee: clayton → kmcclusk
Nasty regression, breaks multi-window browing and breaks view-source. Nominating for mozilla0.8 and raising severity to major.
Severity: normal → major
Keywords: mozilla0.8
I removed my painting changes and the bug still occurs.
The display is cleared by a viewmanager created by an (about:blank) document.The viewmanager used to display the source in viewsource does it correctly then the viewmanager created for about:blank renders the a white rectangle over the top of it. In the past, I believe the (about:blank) document was being destroyed when the document to display arrived. Now it seems to be hanging around. CC'ing adamlock@netscape.com Adam: Is this something you have been working with?
I don't think it's anything I've been working on, because the bug happens in a build way before my recent changes to the "_blank" target code. Could it some kind of crazy race condition where about:blank is loaded, followed by the proper URL but the original URI load is not aborted properly so it still feeds in content?
Whiteboard: critical for 0.8
The about:blank document is create by nsFrameFrame in nsHTMLFrameInnerFrame::DoLoadURL(nsIPresContext* aPresContext) Eric: Should the newly created browser windows or viewsource windows create the about:blank document at all?
Ok, further investigation reveals: The nsFrameFrame is getting the about:blank URI from it's content which is a XULElement. The XUL file for view source is located in: mozilla/xpfe/browser/resources/content/viewSource.xul This file includes the following line: <browser id="content" type="content-primary" name="content" src="about:blank" flex="1"/> This line was changed by disttsc%bart.nl to from a <iframe> tag instead of an <browser> tag. on 1/30/2001. Does the <browser> tag create an additional iframe which also loads about:blank? So maybe changing back to an iframe will fix the problem? CC'ing some XUL guys.
This looks like a chrome issue? any takers?
kevin: does backing jag out fix it? =>jag
Assignee: kmcclusk → disttsc
> Does the <browser> tag create an additional iframe which also loads > about:blank? That would be a bit strange, why would a <browser> tag have an additional iframe (and thus two view managers?) racing to display something on the screen? > So maybe changing back to an iframe will fix the problem? Well, it might work around it, but this should work with a <browser> and if that's broken then that should be fixed.
Hrm, too many "that"s: If <browser/> doesn't work correctly, it should be fixed. Anyway, if reverting to <iframe/> makes things work we could land that on the 0.8 branch (I'd also have to add some methods to the iframe xbl binding), unless of course we find out what's really going on and have a fix in time :-)
Changing the tag in viewSource.xul from an <browser> to <iframe> fixed the refresh problem, but it did not display the source correctly. Instead of showing the actual page source it displayed: <HTML><BODY></BODY></HTML>
Kevin: you'll need to apply that patch for <iframe/> to work (again) in view source.
> <HTML><BODY></BODY></HTML> Btw, that's the html source of about:blank.
Jag: your patch fails when I try to apply it to a pull from today. Can you update your patch? Thanks
I've updated, did another diff, no changes since the last one. How is it failing?
What's the deail with this bug? This is a 0.8 bug so we're trying to get as much movement as possible. Who is waiting on who, etc?
67046,68052,68008 might be dups.
Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: xulBindings.xml |================================================================= |RCS file: /cvsroot/mozilla/xpfe/global/resources/content/xulBindi |retrieving revision 1.53 |diff -u -r1.53 xulBindings.xml |--- xulBindings.xml 2001/02/06 05:33:28 1.53 |+++ xulBindings.xml 2001/02/09 17:59:49 -------------------------- Patching file xulBindings.xml using Plan A... Hunk #1 failed at 590. 1 out of 1 hunks failed--saving rejects to xulBindings.xml.rej done I also tried manually appling the patch and rebuilding mozilla/xpfe - but now I get endless "XUL Binding ASSERTIONS". Jag: Do you see the refresh problem after reverting from <browser> back to <iframe>? The problem is very reproducible for view source. Just bring up a view-source window, shrink it so it is smaller than the browser window and center it over the top of the browser-window. Use the WIN32 taskbar to flip between the view-source and browser-window. When view-source is brought to the top it will be blank or partially rendered. Btw - The ctrl-n case will also have to be fixed. Bringing up a new browser window also creates a lurking about-blank document.
Help: Could a chrome/xul guru try reverting from <browser> to <iframe> in the viewSource.xul file and make the associated changes in Jag's patch?
Did that, didn't fix it. So how come we have two view managers?
Anyone with linux or mac who can check if we have two view managers on there too?
The two view managers are the result of two separate documents being loaded. One document is about:blank. The other document is actual view source content. The question, is why is there a separate about:blank document loaded which doesn't goaway when the view source content arrives. If I do a view source in the viewer app it does not create the about:blank document and it does not exhibit the refresh bug.
Is this perchance related to bug 66029 ?
So what we have found so far is that a QI to nsIMarkupDocumentViewer is related to this... By replacing docShellElement.markupDocumentViewer.defaultCharacterSet = arrayArgComponents[1]; with the fully expanded steps (hidden by xbl in xulBindings.xml): var ds = docShellElement.docShell; var cv = ds.contentViewer; // var mv = cv.QueryInterface(Components.interfaces.nsIMarkupDocumentViewer); // mv.defaultCharacterSet = arrayArgComponents[1]; and commenting out the last two lines view-source works fine again except that the defaultCharacterSet isn't correct. Just commenting out the last line doesn't do the trick, suggesting the QI does something strange. Why uncommenting the QI line messes things up here is a riddle to me.
*** Bug 68476 has been marked as a duplicate of this bug. ***
If you read bug 68476, you'll have an idea of what I'm about to say. I noticed that at a select few URLS, you get a "white box" when you select View, Page Source. Two example URLS are www.google.com and http://www.zeldman.com/askdrweb/ In actuality, you can see the correct content being drawn for a split second before it is covered up with a white box. This happens EVERY TIME for these URLS. The moment you scroll or resize the white box, starts working as advertised. Also, if you use the context menu of the right mouse button to view source, the problem is NOT revealed, ie works as advertised. Hope this bit of info helps you track down the problem.
Sorry - one more note - this bug will ONLY occur if the new Page Source window shows up where the mouse cursor is located. If you open a window, move it way to the right, close it, then open a new one, the problem is gone. Or move the mouse cursor to the edge of the screen and use the keyboard shortcut to open the window - CTRL-U. I was wrong in the last comment when I said the problem will not show up using the context menu of right mouse button to bring up page source - As long as the mouse is within the area the new Page Source View window shows up at, the problem will occur.
Backed myself out on the 0.8 branch. We need a better fix for 0.9 though.
Keywords: mozilla0.8
Whiteboard: critical for 0.8
Target Milestone: --- → mozilla0.9
i second sfraser's assertion that this might be related to 66029
*** Bug 68628 has been marked as a duplicate of this bug. ***
A linux bug surfaced at around the same time: bug 67442, where "open link in new window fails w/err.msg.
Attached patch patch 1 — — Splinter Review
Attached patch patch 1 — — Splinter Review
The above patch (discussed with Peter on IRC) backs out only the parts of the earlier change necessary to fix this bug. It does not address the real problem - why does moving setting of the character set into js cause the document to linger? At any rate, perhaps this can be used as a fall back fix if we run out of time in 0.9...
I'm not seeing the problem in build 2001021417 (Win98) now, so I guess the patch works.
I didn't think it had been checked in. I still get the problem on 2001021420 on win2k.
No, this was only backed out on the branch, the trunk still has this problem. One suggestion is that JS holds on to the content viewer until garbage collection happens, which messes up the lifetime of this object. One solution would be to explicitely tell this object to go away, and have some way to cleanly handle calls to the invalidated object. Ugh. Someone shoot me.
Extending the lifetime of the object would only cause detectable problems if we're actually *doing* things from the destructor, which we shouldn't be, because: * it makes leaks cause other problems * when GC is involved, an object's lifetime may end a bit after it becomes unreachable and the user action ought to happen * when GC is involved, you don't want to do anything from destructors that would cause allocation (although that would cause a JS_ASSERT already) We've run into problems before with the destructor of DocumentViewerImpl doing too much -- see bug 61840, and we never completely fixed those problems.
Yes. The problem here is a jag who knew just enough to be dangerous. When I changed the interface from a .h to a .idl, I had no idea about this stuff. Now I'm beginning to understand the ramifications of such changes, and have some ideas about how to fix this, but I would appreciate help with it.
*** Bug 69105 has been marked as a duplicate of this bug. ***
If the problem is the document viewer's lifetime, the patch I just attached to bug 61821 ought to help.
*** Bug 65950 has been marked as a duplicate of this bug. ***
just add me to the cc-list, because it seems to be connected to bug 67442, which is really annoying!
Important: It is believed that this bug may stop Bugzilla Helper from working with recent Mozilla builds (bug 67046). This makes it reasonably important, and definitely dogfood :-) Gerv
I tested the helper with the 2001022306 linux mozilla build on RedHat6.2, the 2001022209 win32 mozilla build on NT and the 2001022304 mac mozilla build on OS9 and was unable to reproduce any failures in the Helper.
*** Bug 70025 has been marked as a duplicate of this bug. ***
My bug 70025 was different than this. 66034: content disappears. 70025: content never shows up. However, Build 2001022311 has fixed 70025 for me :o)
*** Bug 70438 has been marked as a duplicate of this bug. ***
I want to note this bug only seems to get worse recently. I am seeing it more and more frequently with pages disappearing when I switch windows and Page At best this makes using Mozilla a very irritating experience and at worse it makes it unusable. Source never showing up unless I highlight it. To be clear this is a Windows only problem. I nominate this for mostfreq keyword since the number of duplicates we have of it. Feel free to add it if you agree.
8 dups, close enough.
Keywords: mostfreq
Nominating for mozilla0.8.1: really bad regression, 8 duplicates.
Keywords: mozilla0.8.1
Maybe report of bug 70901 may give some new possibilities to find cure for this strange disappearance.
*** Bug 69498 has been marked as a duplicate of this bug. ***
*** Bug 70901 has been marked as a duplicate of this bug. ***
On 2001-03-09 at 19:19 I checked in the fix to bug 61821 that we once (see 2001-02-15 comments) thought would fix this, but that somebody tested to determine that it did not fix this bug. Blake mentioned on IRC that he thought this bug went away in yesterday's builds. So perhaps that fix worked after all? Are others still seeing this bug?
Nope. What with the bugzilla fun and all I forgot to mention I checked in something similar to pollmann's "patch 1". Note that this bug isn't fixed, just being worked around.
Status: NEW → ASSIGNED
Keywords: mozilla0.8.1
I see this bug with build 2001031904 / win2k
I don´t know why, but this seem to be fixed with 2001032004. Sorry for the SPAM
*** Bug 71414 has been marked as a duplicate of this bug. ***
*** Bug 66029 has been marked as a duplicate of this bug. ***
The problem seems to be gone with 0.8.1, using Win98. Can anyone confirm otherwise?
jag: Are we leaving this open until you do a proper fix rather than a workaround? Gerv
Yeah. I suspect this is still happening, just a lot less. Reducing severity, resetting the milestone, marking this as depending on a bug which I suspect is this issue's root bug so I can undo this hack.
Severity: major → normal
Depends on: 76024
Target Milestone: mozilla0.9 → ---
Has anyone seen this bug recently? Is there any reason to keep it alive except that the fix was "a hack"?
Mass move to jaggernaut@netscape.com
Assignee: jag → jaggernaut
Status: ASSIGNED → NEW
Yes, we need to keep this bug alive because the hacky fix is not only evil, but also papering over the real problem, namely that we're keeping ca. 800kB alive through the xul document, there are weird side effects because of this, and last I checked there were at least two more ways to trigger this. See bug 76024 for example.
->moz1.0
Target Milestone: --- → mozilla1.0
*** Bug 67442 has been marked as a duplicate of this bug. ***
Summary: Content in Mozilla disappears seemingly at random → Content in Mozilla disappears seemingly at random [open link in new window breaks at times]
Blocks: 104166
Need to play with this one -> 0.9.8
Target Milestone: mozilla1.0 → mozilla0.9.8
- appCore.setDefaultCharacterSet(arrayArgComponents[1]); //XXXjag see bug 67442 + getMarkupDocumentViewer().defaultCharacterSet = arrayArgComponents[1]; With that change to navigator.js, I don't see the above mentioned problems. If I recall correctly the bug that line was triggering was fixed a while ago. See bug 46200, where it's part of a larger patch to kill off nsIBrowserInstance some more.
So is that all we need to fix this? if so, sr=alecf on that change
Well, currently we're not seeing the problem 'coz we're avoiding it. I'm only asserting that even by not avoiding the problem we're still not seeing it.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: