[Webshell] A web shell without a document should display something

VERIFIED FIXED in mozilla0.9



20 years ago
18 years ago


(Reporter: karnaze, Assigned: waterson)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(11 attachments)



20 years ago
There are 2 cases in which this comes up. First, if viewer loads a url that
doesn't exist, then nothing gets displayed. In this case a simple document
should probably get constructed containing a root and a body at the least.

Second, in the following example, the 1st <frame> doesn't get an nsWebShell
because there is no src attribute and so I can paint the background color of the
<frame> and it will stand. But in the 2nd <frame> there is a web shell and if I
paint the background color of the <frame>, it gets wiped out by web shell in the
sub doc (of the doc that doesn't exist). Since this happens, I now only paint
the background in nsHTMLFrameInnerFrame::Paint() if there is a web shell.

<frameset rows=*,*>
  <frame src=DoesNotExist.html>


20 years ago
Assignee: nisheeth → harishd

Comment 1

20 years ago
Both the cases can be fixed if the content sink or the parser checks to see
whether the current document is empty, and if it is, constructs an "empty"
content model with just the root and body elements.

I'm putting myself on the cc list, assigning this to Harish and ccing Rick.


20 years ago
Component: other → Parser
QA Contact: 3853 → 3847


20 years ago
Assignee: harishd → dp

Comment 2

20 years ago
Looks like netlib is not communicating with the document on a *file error*.
Assigning bug to dp@netscape.com
Waoiting on necko landing. Then needs to be verified.
Assignee: dp → warren
Component: Parser → Networking Library
Target Milestone: M9

Comment 4

20 years ago
just an fyi -- i was testing out bug #5374 and accessed a frameset that did not
have the SRC name value pair and the app crashed. The incident # is 9382619, the
trace is this:
  this = 0x08b116b4
     (*this) = Data not available
  aPresContext = 0x082dfca8
     (*aPresContext) = Data not available
  aStatus = 0 (0x00000000)
  display = 0x082dfca8
     (*display) = Data not available
  view = 0x00000000
     (*view) = Data not available
  oldVis = 145823412 (0x08b116b4)


20 years ago
Depends on: 7232

Comment 5

20 years ago
Deferring until necko landing.


20 years ago
No longer depends on: 7232


20 years ago
Blocks: 7232

Comment 6

20 years ago
Changing all Networking Library/Browser bugs to Networking-Core component for

Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do
this in a bulk change.  If this happens, I will fix. ;-)


20 years ago
Assignee: warren → dp

Comment 7

20 years ago
I don't know how I ended up with this one. This doesn't seem to be a necko


20 years ago
Assignee: dp → harishd
harish, Can you see if this is still a netlib problem.


20 years ago
Assignee: harishd → nisheeth

Comment 9

20 years ago
After talking to nisheeth, it looks like the problem could actually be at the
webshell level.  Assigning bug to nisheeth@netscape.com and adding myself to the
CC list.


20 years ago
Target Milestone: M9 → M10

Comment 10

20 years ago
This bug is not an M9 stoppper.  Changing milestone to M10...


20 years ago

Comment 11

20 years ago
CCing Scott Collins, new webshell owner...


20 years ago
Summary: A web shell without a document should display something → [Webshell] A web shell without a document should display something

Comment 12

20 years ago
Bul re-assigning webshell bugs to the new webshell owner, Scott Collins.  Scott,
please adjust the target milestone assignments as you see fit.  Thanks.


20 years ago
Severity: normal → critical
Priority: P3 → P2
Summary: [Webshell] A web shell without a document should display something → [Webshell] [beta] Crash: A web shell without a document should display something
Target Milestone: M10 → M12

Comment 13

20 years ago
since this is a crash (acccording to beppe), raised it's priority and set
milestone to M12.


20 years ago
Blocks: 14469


20 years ago
Blocks: 15160


20 years ago
No longer blocks: 14469

Comment 14

20 years ago
Is this bug still valid? If not, let's get rid of it.

Comment 15

20 years ago
(Mass-) Re-assigning [Webshell] bugs to travis, on the advice of dp, et al.  Many
of these may be invalid in the new world of the re-written webshell, but he
certainly needs to be aware of these issues.  Hope this helps you, travis.


20 years ago
Depends on: 13374

Comment 16

20 years ago
Move to M13 and re-assess once basic Webshell re-design is complete.

Comment 17

20 years ago
Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.


20 years ago
Target Milestone: M13 → M14

Comment 18

20 years ago
Move to M14.


20 years ago
Closed: 20 years ago
Resolution: --- → WORKSFORME

Comment 19

20 years ago
I thought rickG had set up the parser to create an empty document if the
document was empty.  There are not real test cases attached here.  So I am
marking this as worksforme.  Karnaze, if the problem you thought was originally
there is still there can you put a test case up or talk to me about what I am
not seeing in your initial writeup?

Comment 20

20 years ago
If the URL doesn't exist, the parser is never called so it cant fabricate an
empty document. (Also true when the document has no file extension, but that
bug is assigned to jud.)

I had never thought to address the empty frame problem cited below. I'll take a
quick look to see what I can do at the parser level.

Comment 21

20 years ago
Mozilla now brings up an alert when a non existant url is entered, which is the 
same behavior as Nav. 

Using testcase from bug beppe mentions, I find that a frame is painted over 
whatever you had on the page before calling up the testcase.  For example, I had 
a directory up and when I clicked on the testcase, the directory still showed 
through the frames that were drawn by the testcase.  

This is happening on Windows and Mac, but not on Linux.  Since there is no 
option under Platform/OS for "most" I'm marking it all/all.

I will attach the testcase.  
Reopening bug.
OS: Windows NT → All
Hardware: PC → All
Resolution: WORKSFORME → ---

Comment 22

20 years ago
Posted file attaching testcase

Comment 23

20 years ago
Adding "crash" keyword.
Keywords: crash

Comment 24

20 years ago
Due to Beta indication in Summary, putting beta1 into keyword field.
Keywords: beta1


20 years ago
Summary: [Webshell] [beta] Crash: A web shell without a document should display something → [Webshell]Crash: A web shell without a document should display something

Comment 25

20 years ago
This needs to be fixed by beta. Travis testcases have been provided. We'd like 
status from you; otherwise it's PDT+.
Keywords: crash
Summary: [Webshell]Crash: A web shell without a document should display something → [Webshell] A web shell without a document should display something
Whiteboard: [PDT+]
*** Bug 7289 has been marked as a duplicate of this bug. ***
This can also be seen in the sidebar. Disconnect yourself from the network,
and try to bring up an external sidebar panel -- it doesn't redraw, so you just
get the remnants of the previous panel.


20 years ago
Whiteboard: [PDT+] → [PDT+] 2/25

Comment 28

20 years ago
Changing to beta2 keyword, removing from PDT+
Keywords: beta1beta2
Whiteboard: [PDT+] 2/25

Comment 29

20 years ago
*** Bug 30950 has been marked as a duplicate of this bug. ***


20 years ago

Comment 30

20 years ago
Ok, so this basically happens because the docshell that is there doesn't have a 
content viewer at the point this happens.  There are really two fixes for 
this...  One is that there should always be a contentViewer (at least one for 
about:blank) when the frame is visible.  This would fix this as well as other 
focus bugs that assert when trying to get the content viewer, presShell and 
other assorted things out of the docShell before a contentViewer has loaded.  
The problem here however is that I don't really know when to create the content 
Viewer.  I don't really want to create a content viewer that is then 
immiedately killed by the loading of about:blank.  So I could create it when 
Visibility is set to true on the docshell, this however happens pretty 
instantly too without regard for if the frame is really visible or not.

Another solution would be to do what is done when the frame doesn't have a 
docShell...  Look at 
p#616.  That line could be if(!mDocShell || !docShellContentViewer).  The 
docShellContentViewer would of course have to be pulled out of the docShell 
before the if statement.  This would do the painting for us.  This however 
would not fix the focus, problems, but would allow me to fix the focus problems 
by not creating that viewer until it was asked for.

Comment 31

20 years ago
See related bug 30950

Comment 32

20 years ago
Day late and a dollar short, looks like Travis already duped this.  Thanks
Travis!  :)

Comment 33

20 years ago
Moving to M15.

Travis, should this be moved to M16?

Target Milestone: M14 → M15

Comment 34

20 years ago
Can someone on the CC scroll up and look at my comments from a couple of weeks 
ago and possibly comment on the direction to go with this?  Something we want 
to do in layout?

Comment 35

20 years ago
Travis, the fix you mentioned here:


Seems like a reasonable step towards getting the right behaviour.  I'm not sure
I understand the focus issues, or how you would solve them, but the fix you
mentioned is definitely better than the way things are today.


20 years ago
Blocks: 34143


20 years ago
Blocks: 34171

Comment 36

20 years ago
M16 ...
Target Milestone: M15 → M16

Comment 37

20 years ago
*** Bug 35214 has been marked as a duplicate of this bug. ***

Comment 38

20 years ago
*** Bug 35214 has been marked as a duplicate of this bug. ***


19 years ago
Blocks: 33459
*** Bug 36335 has been marked as a duplicate of this bug. ***


19 years ago
Keywords: nsbeta2
*** Bug 36521 has been marked as a duplicate of this bug. ***

Comment 41

19 years ago
Putting on [nsbeta2+] radar.  
Keywords: beta2
Whiteboard: Putting on [nsbeta2+] radar.

Comment 42

19 years ago
Fixing Status Whiteboard to read correctly to pick up on my queries.
Whiteboard: Putting on [nsbeta2+] radar. → [nsbeta2+]

Comment 43

19 years ago
per valeski request - Putting on [nsbeta2-] radar. 
Whiteboard: [nsbeta2+] → [nsbeta2-]

Comment 44

19 years ago
*** Bug 35128 has been marked as a duplicate of this bug. ***

Comment 45

19 years ago
M16 has been out for a while now, these bugs target milestones need to be 

Comment 46

19 years ago
*** Bug 43268 has been marked as a duplicate of this bug. ***

Comment 48

19 years ago
*** Bug 47219 has been marked as a duplicate of this bug. ***

Comment 49

19 years ago
*** Bug 47072 has been marked as a duplicate of this bug. ***


19 years ago
Keywords: mostfreq

Comment 50

19 years ago
*** Bug 48682 has been marked as a duplicate of this bug. ***

Comment 51

19 years ago
We should really do this for beta3...
Keywords: nsbeta3


19 years ago
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]


19 years ago
Priority: P2 → P1

Comment 52

19 years ago
changing qa contact to tever
QA Contact: janc → tever

Comment 53

19 years ago
I suggest to change Milestone to M18 ;-)

Comment 54

19 years ago
Is there anyone working/making progress on this? The last technical comment is 
six months old, but this bug is one of the ones most people trip over and it's 
marked both nsbeta3+ and P1.

Since I got the impression that it might include some architectural changes, I'm 
afraid putting it off too much into the future will mean that it won't get fixed 
for Netscape's release.
Target Milestone: M16 → ---

Comment 55

19 years ago
PDT thinks we can live without this for N6. Marking P3/nsbeta3-
Priority: P1 → P3
Whiteboard: [nsbeta2-][nsbeta3+] → [nsbeta2-][nsbeta3-][PDTP3]
*** Bug 48480 has been marked as a duplicate of this bug. ***
Another case where the webshell lacks a document is hitting the stop button
after the current document has been destroyed, but before the new document
loads. See bug 48480.

Adding attinasi to CC list.
This bug happens a quite a bit if you don't have a fast (or good) connection, or
if you're talking to sites that are slow (and you get tired of waiting). It
really looks bad, too. I'd be VERY tempted to renominate for nsbeta3, but I
don't think it's within my purview to do so. (I reported 48480, just marked as a
dup). This is more serious than a frame that points to a non-existant page.

Adding Kevin M. to the cc list.

I think it should be re-evaluated by the PDT team. Maybe it'll be minus'd again,
but the problem is more frequent than they knew when they evaluated it before.
Kevin? Eric?  Anyone?  Comments?

Comment 59

19 years ago
Randell, anyone can take off the [nsbeta3-] to request re-evaluation. I've done
it here, but you could have too.

I don't think I've seen this bug. Is the symptom that once you try to load a
slow or nonexistent page, the window never shows a title for any subsequently
loaded pages? Or is it just that the title is blank for the nonexistent page?
Whiteboard: [nsbeta2-][nsbeta3-][PDTP3] → [nsbeta2-][PDTP3]

Comment 60

19 years ago
This bug has lots of symptoms as seen in all the duplicates. The problem is that 
sometimes there is no document in the webshell. I, for instance stumbled upon it 
the first time when a link was followed but the server failed to answer in some 
way. The result was a page that _looked_ like the original page since nothing 
had been drawn upon the old content but nothing on it worked. Not the scrollbar, 
not the links, nothing. It looked like the browser had hang. It gave a very bad 
impression and it wasn't until I found this I understood it was benign. 

Also, if putting a window in front of Mozilla and then removing that window, the 
content area isn't redrawn, but contains the content of the other window.
Keywords: rtm

Comment 61

19 years ago
There is always be a document viewer always a document associated with a 
docshell. The docshell does not replace the old document viewer until the new 
viewer has been created and associated with a new document. After that the 
docshell immediately disposes of the old document viewer and initialises the new 
one with the window widget it's place.

So the rendering problems are nothing to do with missing document viewers or 
documents because there is no time when the window is without either.

Paint events not being processed until after the initial reflow seems to be the 
cause. It might be possible to force a reflow to happen sooner so I'm 
investigating along those lines. Assigning to me.
Assignee: valeski → adamlock
I think the problem is there isn't a CanvasFrame around to paint the windows
contents. Without a least one frame around which now's how to paint the extent
of the damaged rect nothing will get painted even though paint messages are

Comment 63

19 years ago
rtm-, no high frequency terrible consequence is described for this bug.  If you 
can describe such, please update the bug.
Whiteboard: [nsbeta2-][PDTP3] → [nsbeta2-][PDTP3][rtm-]
*** Bug 57339 has been marked as a duplicate of this bug. ***
*** Bug 57339 has been marked as a duplicate of this bug. ***
Replacing nsbeta[23] and rtm keywords with mozilla0.9.

Keywords: nsbeta2, nsbeta3, rtmmozilla0.9


19 years ago
Target Milestone: --- → mozilla0.9


19 years ago
Blocks: 55860
Cleaning out old status garbage.
This is a mostfreq, and it also costs us on performance when using a slow
rendering channel (such as remote X).  This bug has been open for over 2 years;
let's try to get it resolved.  Please.
Keywords: perf
Whiteboard: [nsbeta2-][PDTP3][rtm-]

Comment 68

19 years ago
Reassigning to the layout team in the hope of kickstarting this bug again.

Essentially it looks like some frame is not painting it's background either 
because it hasn't been initialised yet or it's invisible or it assumes child 
frames will cover it.
Assignee: adamlock → karnaze
Component: Networking → Layout
QA Contact: tever → petersen

Comment 69

19 years ago
Info/specs in bug 24684 could help to resolve this elegantly while at the same
time improving measurable and perceived performance of the browser.
It appears that the transitional states of windows/frames are not yet uncovered
by any standards. Mozilla is in a good position to take the lead here I guess.

Otherwise why do we have "something" in the Summary of this?

Comment 70

19 years ago
Reassiging to buster's list.
Assignee: karnaze → buster

Comment 71

19 years ago
I'm going take this bug, but I'm not sure how to reproduce it. The attached test
case seems to work fine.
Assignee: buster → waterson

Comment 72

19 years ago
Ok, bug 57339 seems to have a test case that's easily reproducable.
This patch changes the view manager to paint something by default when you get
an NS_PAINT event and refreshing is disabled.  Refreshing is disabled in between
presshell destruction and a new presshell being created which is why we get the
blank areas when loading new documents some times.

Waterson is trying to come up with a way to get the last document color so that
we can use it during the transition.  It should be a lot cleaner looking that way.

roc + kevin, what do you guys think?

Comment 76

19 years ago
Patch seems to have some tab problems but looks good to me, r=adamlock

Can you just verify the context isn't been double AddRef'd or anything because 
some of the other code using CreateRenderingContext use getter_AddRefs. See:

Good catch on that leak.  Whew.  As for the tabs, there isn't much I can do
about that.  There are tabs all over the file.  I'm just following the local style.
Use nsViewManager::GetWidgetForView instead of getting the widget directly. That 
function takes care of some corner cases.

If we start some operation that turns off Refresh and then repaint some portion 
of the window, do we get into a situation where the repainted portion is a solid 
background color but the rest of the window has not been updated? That would be 

What we really need is an nsViewManager::SetDocumentBackgroundColor function. 
This should be called by layout at appropriate times. If we had that 
information, not only could we choose a better background color here, but we 
could do platform window clearing and fix other bugs.

Comment 80

19 years ago
Sounds interesting. So that frameset, frame, window,open() can get this color by 
and with additional parameters instead of about:blank or equivalent which has 
the irritating
white default color. Is this not a window thing instead of document?

Comment 81

19 years ago
Adding URL to test case.

Comment 82

19 years ago
The parser receives an OnStartRequest(), and begins to set up the new document 
context, but never receives the matching OnStopRequest() when the load group is 

darin: shouldn't load observers that get OnStartRequest() calls *always* get 
matching OnStopRequests()? Especially if the load has been cancelled? I can dig 
into this to try to figure out what's going wrong, but at this point it looks to 
be a necko problem to me.

For posterity's sake, the way I've been reproducing this bug is to:

1. Go to the above URL (http://www.abika.com/Expert/ExpertView.asp?Category=8)
2. Click on a link (new one each time, to avoid load-from-cache)
3. Try to cancel (hit the ESC key) at ``just the right moment''

Comment 84

19 years ago
Ok, with darin's help, I think we've come just a bit closer to the root cause of 
the problem. The ``cancel'' hits while we're loading one of the document's style 
sheets. The nsCSSLoader's internal state appears to be fscked at this point, and 
it looks like it's not properly unblocking the parser.

Comment 85

19 years ago
Ok, I take it back. It *doesn't* necessarily appear to be a bug with 
nsCSSLoader. The case that appears to break is when we call through to 
nsDocumentOpenInfo::OnStopRequest(). Specifically, ProcessCanceledCase() isn't 
permitting the OnStopRequest() to make it through to the observer. Why's that?

Comment 86

19 years ago
dougt/mscott/valeski, I think you guys blew the On[Start|Stop]Request() symmetry 
here in nsURILoader.cpp. Specifically, the way that you do early returns if  
ProcessCanceledCase() return PR_TRUE guarantees that there are several ways that 
the OnStopRequest() won't get propagated out to the primary observer. I'm not 
exactly sure what you guys were trying to accomplish here. Could one of you 

Comment 87

19 years ago
Moreover, it seems really wrong to be calling ProcessCanceledCase from
OnStartRequest and OnDataAvailable.  If the status of the request is
event... why is that?  I can understand eating an OnDataAvailable, but
we should not be clearing m_targetStreamListener until after OnStopRequest
has fired.
This patch includes changes from roc's comments and is also safer.

Even though waterson is still looking for other problems I think that this
should be checked in so that we don't ever end up with unpainted areas.
Oh, roc you should have a look at this patch and let me know if it's go or no-go
for you.

Comment 91

18 years ago
Actually I did NOT blow the stream listener notifications here, contrary to
popular belief. We had a very specific reason for doing what I did (by not
propogating OnStopRequest calls out in the canceled case). This is because the
cancel was expected to be originaing from the docshell doing the load. We crash
horribly if we try to call OnStopRequest because we were doing so on a deleted
docshell which went away when the user hit stop or otherwise canceled the load.

Please see Bug 40116 for more details as to why we did what we did. 

Comment 92

18 years ago
But mscott, this keeps us from propagating OnStopRequest() out to bona fide 
listeners. Is there a way to differentiate between the two situations? (Are 
there two situations?) I'm sorry, I don't understand this code very well, nor do 
I want to. Help me understand what the right thing to do is here.
mscott: why do you have a pointer to a deleted object?  Shouldn't it be
deregistered at destruction time?

Comment 94

18 years ago
Okay, I think I'm understanding this problem a bit more thoroughly as the 
schedule unfolds. It appears that what's happening is that we're in a state 
where the HTML parser is blocked while a style sheet it loading. When the load 
is cancelled

1. DocumentViewerImpl::Stop() calls nsHTMLDocument::StopDocumentLoad(),
   which calls nsParser::Terminate(). This *doesn't* end up calling the content
   sink's DidBuildModel() (which would close out the tags and do an initial
   reflow) because the parser *isn't* parsing right now. It's been disabled
   because of the style sheet load.

   But now the parser is placed in a state such that its mInternalState is

2. The style sheet completes, and unblocks the parser, but again, none of
   the content is closed out because we've set mInternalState to

3. In my tree, the OnStopRequest() *is* called (because I've undone mscott et
   al's changes), but it has no effect because of the previous state

This is looking like wedgery between the parser and the docshell, and I think 
that it's probably best solved by negotiation between adamlock and harishd.

mscott, I think your fix to bug 40116 smells wrong to me (I really don't like 
how you've broken the On[Start|Stop]Request() symmetry), but I'm at a loss to 
provide something better without understanding the problem more thoroughly.

Comment 96

18 years ago
mscott, the last patch (04/08/01 15:11) makes it so that nsURILoader will call 
through to OnStopRequest() in the cancelled case. FWIW, I went back through all 
the test cases from bug 40116 (and its dups) and could not repro the crash with 
this patch. What do you think?


18 years ago
Blocks: 64833

Comment 97

18 years ago
Posted patch fixSplinter Review

Comment 98

18 years ago
The attached fix:

1. Detects that the parser is blocked when Terminate() is called, and updates
   the parser's mParserEnabled variable s.t. the DTD's DidBuildModel() will
   get called. harishd: should nsParser::DidBuildModel() just *not check*
   mParserEnabled? (Under what other circumstances will this be called?)

2. Fixes the HTML content sink to notice that its DidBuildModel() is being
   called in a situation where the <body> element hasn't been seen yet, and
   forces an initial reflow.

This appears to fix the bug, and although I've got the nsURILoader changes in 
my tree, I don't think they're necessary for this fix.


18 years ago
Keywords: patch

Comment 99

18 years ago
Posted patch real fixSplinter Review

Comment 100

18 years ago
Oops, I attached an earlier rev of the patch (that *doesn't* work). The last 
patch (04/08/01 16:39) is the real fix.
chris, what about attachment 30089 [details] [diff] [review] (Make nsURILoader call OnStopRequest()); Has 
this patch landing on the the cutting room floor?  
*** Bug 72421 has been marked as a duplicate of this bug. ***

Comment 103

18 years ago
Posted patch better fixSplinter Review

Comment 104

18 years ago
Talked with harishd about this, and decided that we just shouldn't be checking
mParserEnabled in DidBuildModel(). It turns out that DidBuildModel() is only
ever called from Terminate(), and from inside ResumeParse(), which already does
the check.

Comment 105

18 years ago

Comment 106

18 years ago
Patch, id=30184, looks good. r=harishd

Comment 109

18 years ago
Fix checked in.
Closed: 20 years ago18 years ago
Resolution: --- → FIXED
I've checked in the view manager patch.

Checking in nsViewManager.cpp;
/cvsroot/mozilla/view/src/nsViewManager.cpp,v  <--  nsViewManager.cpp
new revision: 3.183; previous revision: 3.182

Comment 113

18 years ago
Marking verified in the May 30th build.


18 years ago
No longer blocks: 64833
You need to log in before you can comment on or make changes to this bug.