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

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[karnaze (gone)]

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>
  <frame src=DoesNotExist.html>
</frameset>

Comment 1

[Nisheeth Ranjan]

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.

Comment 2

[harishd]

Looks like netlib is not communicating with the document on a *file error*.
Assigning bug to [e-mail]

Comment 3

[Suresh Duddi (gone)]

Waoiting on necko landing. Then needs to be verified.

Comment 4

[rubydoo123]

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:
nsHTMLFrameInnerFrame::DidReflow
  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)

Comment 5

[Warren Harris]

Deferring until necko landing.

Comment 6

[leger]

Changing all Networking Library/Browser bugs to Networking-Core component for
Browser.

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

Comment 7

[Warren Harris]

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

Comment 8

[Suresh Duddi (gone)]

harish, Can you see if this is still a netlib problem.

Comment 9

[harishd]

After talking to nisheeth, it looks like the problem could actually be at the
webshell level.  Assigning bug to [e-mail] and adding myself to the
CC list.

Comment 10

[Nisheeth Ranjan]

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

Comment 11

[Nisheeth Ranjan]

CCing Scott Collins, new webshell owner...

Comment 12

[Nisheeth Ranjan]

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

Comment 13

[buster]

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

Comment 14

[Warren Harris]

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

Comment 15

[Scott Collins]

(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.

Comment 16

[don]

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

Comment 17

[leger]

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

Comment 18

[don]

Move to M14.

Comment 19

[travis]

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

[rickg]

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

[Jan Carpenter]

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.

Comment 22

[Jan Carpenter]

Attachment: attaching testcase

Comment 23

[leger]

Adding "crash" keyword.

Comment 24

[leger]

Due to Beta indication in Summary, putting beta1 into keyword field.

Comment 25

[rickg]

This needs to be fixed by beta. Travis testcases have been provided. We'd like 
status from you; otherwise it's PDT+.

Comment 26

[Kevin McCluskey (gone)]

*** Bug 7289 has been marked as a duplicate of this bug. ***

Comment 27

[Hixie (not reading bugmail)]

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.

Comment 28

[James Everingham]

Changing to beta2 keyword, removing from PDT+

Comment 29

[travis]

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

Comment 30

[travis]

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 
http://lxr.mozilla.org/seamonkey/source/layout/html/document/src/nsFrameFrame.cp
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

[Eric Pollmann]

See related bug 30950

Comment 32

[Eric Pollmann]

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

Comment 33

[don]

Moving to M15.

Travis, should this be moved to M16?

Comment 34

[travis]

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

[Eric Pollmann]

Travis, the fix you mentioned here:

http://lxr.mozilla.org/seamonkey/source/layout/html/document/src/nsFrameFrame.cpp#616

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.

Comment 36

[don]

M16 ...

Comment 37

[John Morrison]

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

Comment 38

[John Morrison]

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

Comment 39

[Asa Dotzler [:asa]]

*** Bug 36335 has been marked as a duplicate of this bug. ***

Comment 40

[Asa Dotzler [:asa]]

*** Bug 36521 has been marked as a duplicate of this bug. ***

Comment 41

[leger]

Putting on [nsbeta2+] radar.  

Comment 42

[leger]

Fixing Status Whiteboard to read correctly to pick up on my queries.

Comment 43

[leger]

per valeski request - Putting on [nsbeta2-] radar. 

Comment 44

[Adam Lock]

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

Comment 45

[Mike]

M16 has been out for a while now, these bugs target milestones need to be 
updated.

Comment 46

[Eric Pollmann]

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

Comment 47

[Dawn Endico]

Reassigning all travis bugs to Valeski for triage. Don thought these were
all docshell related. Travis is no longer at netscape so these bugs are
unowned.

I'm reassigning 23 bugs to Valeski right now. To search for them,
search for "BUGSFORMERLYKNOWNASTRAVIS" in the description. The url below 
should work.

http://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=&short_desc_type=substring&long_desc=BUGSFORMERLYKNOWNASTRAVIS&long_desc_type=substring&bug_file_loc=&bug_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time

Comment 48

[Blake Ross]

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

Comment 49

[Adam Lock]

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

Comment 50

[Blake Ross]

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

Comment 51

[Blake Ross]

We should really do this for beta3...

Comment 52

[Jan Carpenter]

changing qa contact to tever

Comment 53

[Tobias Burnus]

I suggest to change Milestone to M18 ;-)

Comment 54

[Daniel Bratell]

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.

Comment 55

[Phil Peterson]

PDT thinks we can live without this for N6. Marking P3/nsbeta3-

Comment 56

[Kevin McCluskey (gone)]

*** Bug 48480 has been marked as a duplicate of this bug. ***

Comment 57

[Kevin McCluskey (gone)]

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.

Comment 58

[Randell Jesup [:jesup] (needinfo me)]

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

[Phil Peterson]

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?

Comment 60

[Daniel Bratell]

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.

Comment 61

[Adam Lock]

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.

Comment 62

[Kevin McCluskey (gone)]

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
generated.

Comment 63

[selmer (gone)]

rtm-, no high frequency terrible consequence is described for this bug.  If you 
can describe such, please update the bug.

Comment 64

[Kevin McCluskey (gone)]

*** Bug 57339 has been marked as a duplicate of this bug. ***

Comment 65

[Kevin McCluskey (gone)]

*** Bug 57339 has been marked as a duplicate of this bug. ***

Comment 66

[Brendan Eich [:brendan]]

Replacing nsbeta[23] and rtm keywords with mozilla0.9.

/be

Comment 67

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 68

[Adam Lock]

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.

Comment 69

[bht237]

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

[karnaze (gone)]

Reassiging to buster's list.

Comment 71

[Chris Waterson]

I'm going take this bug, but I'm not sure how to reproduce it. The attached test
case seems to work fine.

Comment 72

[Chris Waterson]

Ok, bug 57339 seems to have a test case that's easily reproducable.

Comment 73

[Judson Valeski]

is http://bugzilla.mozilla.org/show_bug.cgi?id=41116 a dupe of this?

Comment 74

[Christopher Blizzard (:blizzard)]

Attachment: patch

Comment 75

[Christopher Blizzard (:blizzard)]

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

[Adam Lock]

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:

http://lxr.mozilla.org/seamonkey/source/view/src/nsViewManager2.cpp#509

Comment 77

[Christopher Blizzard (:blizzard)]

Attachment: patch #2

Comment 78

[Christopher Blizzard (:blizzard)]

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.

Comment 79

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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 
bad.

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

[bht237]

Sounds interesting. So that frameset, frame, window,open() can get this color by 
inheritance
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

[Chris Waterson]

Adding URL to test case.

Comment 82

[Chris Waterson]

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 
cancelled.

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 83

[Chris Waterson]

Attachment: output with NSPR_LOG_MODULES=nsHTTPProtocol:5

Comment 84

[Chris Waterson]

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

[Chris Waterson]

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

[Chris Waterson]

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?

Comment 87

[Darin Fisher]

Moreover, it seems really wrong to be calling ProcessCanceledCase from
OnStartRequest and OnDataAvailable.  If the status of the request is
NS_BINDING_ABORTED or NS_ERROR_DOM_RETVAL_UNDEFINED, then we eat the
event... why is that?  I can understand eating an OnDataAvailable, but
we should not be clearing m_targetStreamListener until after OnStopRequest
has fired.

Comment 88

[Christopher Blizzard (:blizzard)]

Attachment: die, 80th column, die! ( new patch from comments )

Comment 89

[Christopher Blizzard (:blizzard)]

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.

Comment 90

[Christopher Blizzard (:blizzard)]

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

[Scott MacGregor]

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

[Chris Waterson]

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.

Comment 93

[Mike Shaver (:shaver emeritus)]

mscott: why do you have a pointer to a deleted object?  Shouldn't it be
deregistered at destruction time?

Comment 94

[Chris Waterson]

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
   NS_ERROR_HTMLPARSER_STOP_PARSING, so...

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

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
   transitions.

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 95

[Chris Waterson]

Attachment: Make nsURILoader call OnStopRequest(), even if request has been cancelled

Comment 96

[Chris Waterson]

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?

Comment 97

[Chris Waterson]

Attachment: fix

Comment 98

[Chris Waterson]

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.

Comment 99

[Chris Waterson]

Attachment: real fix

Comment 100

[Chris Waterson]

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.

Comment 101

[Doug Turner (:dougt)]

chris, what about attachment 30089 [details] [diff] [review] (Make nsURILoader call OnStopRequest()); Has 
this patch landing on the the cutting room floor?  

Comment 102

[Kevin McCluskey (gone)]

*** Bug 72421 has been marked as a duplicate of this bug. ***

Comment 103

[Chris Waterson]

Attachment: better fix

Comment 104

[Chris Waterson]

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

[Chris Waterson]

Attachment: even better fix

Comment 106

[harishd]

Patch, id=30184, looks good. r=harishd

Comment 107

[Chris Waterson]

Attachment: make Terminate() return result instead of mInternalState

Comment 108

[Johnny Stenback (:jst)]

sr=jst

Comment 109

[Chris Waterson]

Fix checked in.

Comment 110

[Robert O'Callahan (:roc) (email my personal email if necessary)]

sr=roc+moz for http://bugzilla.mozilla.org/showattachment.cgi?attach_id=30046

Comment 111

[Brian Ryner (not reading)]

r=bryner for http://bugzilla.mozilla.org/showattachment.cgi?attach_id=30046

Comment 112

[Christopher Blizzard (:blizzard)]

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

[Chris Petersen]

Marking verified in the May 30th build.