467853 - Firefox 3.1 builds choke on certain sizeToContent calls and produce NS_ERROR_FAILURE exceptions

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[Eric Appleman]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.4) Gecko/2008111616 Ubuntu/9.04 (jaunty) Firefox/3.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.4) Gecko/2008111616 Ubuntu/9.04 (jaunty) Firefox/3.0.4

Almost all sizeToContent calls in Firefox 3.1 (all platforms) are
not handled properly and cause rendering and/or redraw errors.

Reproducible: Always

Steps to Reproduce:
(Note: I am a Text-to-Image developer)

1. Install the Text-to-Image addon.
2. Install and select iFox Graphite theme.
3. Restart Firefox.
4. Find an image URL: http://www.mozilla.com/img/tignish/home/feature-logo.png
5. Enable Text-to-Image by clicking once on the red hurricane icon in the
status bar.
6. Double click on the image that has now appeared.
7. Observe the "window" that results.

Further examples of unpredictable sizeToContent behavior:

https://bugzilla.mozilla.org/attachment.cgi?id=276818
https://bugzilla.mozilla.org/attachment.cgi?id=304326
https://bugzilla.mozilla.org/attachment.cgi?id=276997

Comment 1

[Eric Appleman]

Build used and breakpoints

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2) Gecko/20081128 Ubuntu/9.04 (jaunty) Shiretoko/3.1b2 ID:20081128200629


Breakpoint 1, DocumentViewerImpl::SizeToContent (this=0xac0bf6a0) at
nsDocumentViewer.cpp:3137
3137 nsDocumentViewer.cpp: No such file or directory.
in nsDocumentViewer.cpp
Current language: auto; currently c++

Run till exit from #0 DocumentViewerImpl::SizeToContent (this=0xac0bf6a0) at
nsDocumentViewer.cpp:3137
0xb704eb88 in nsGlobalWindow::SizeToContent (this=0xaafee330) at
nsGlobalWindow.cpp:4546
4546 nsGlobalWindow.cpp: No such file or directory.
in nsGlobalWindow.cpp
Value returned is $1 = 2147500037

Comment 2

[Damian Shaw [Quan]]

I can confirm that:

https://bugzilla.mozilla.org/attachment.cgi?id=276818
https://bugzilla.mozilla.org/attachment.cgi?id=276997

Produce such errors in the error console. I'm assuming the STR given is an overly complicated example.

Comment 3

[Eric Appleman]

The URL below is a sizeToContent test case that consistently crashes Firefox for
me when playing around with the buttons:

https://bugzilla.mozilla.org/attachment.cgi?id=349968

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2) Gecko/20081128 Ubuntu/9.04
(jaunty) Shiretoko/3.1b2 ID:20081128200629

Comment 4

[Eric Appleman]

BTW, crash is perhaps not the best term.

Rather, the process remains but the browser vanishes from the screen and taskbar.

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

Move this slightly closer to the correct component.

Comment 6

[Eric Appleman]

Thanks.

Hopefully further triaging will help this bug move along.

Comment 7

[Damian Shaw [Quan]]

I tested this on Windows.

Comment 8

[u88484]

(In reply to comment #7)
> I tested this on Windows.
Ok, I was talking to Eric last night on IRC trying to reproduce this and I could not using the latest trunk builds on Vista.  Builds which he confirmed still showed this bug.

Damian, can you still reproduce this with 3.0.5, Firefox 3.1 beta 3, Minefield 3.2a1pre?

Comment 9

[Damian Shaw [Quan]]

https://bugzilla.mozilla.org/attachment.cgi?id=276997

gives me:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindow.sizeToContent]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: https://bugzilla.mozilla.org/attachment.cgi?id=276997 :: <TOP_LEVEL> :: line 10"  data: no]

on:

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b3pre) Gecko/20081220 Shiretoko/3.1b3pre ID:20081220041002

If there's anything more specific your asking me to do, I'll be happy to test.

Comment 11

[Daniel Holbert [:dholbert]]

FWIW: This behavior regressed as a result of bug 465843 landing.  See duplicate-bug bug 472740 comment 7 (and the few comments before & after) for more info.

Comment 12

[Johnny Stenback (:jst)]

Not blocking on this, but this doesn't sound serious enough to hold the release for. If this manifests itself in more common ways as well, we'll reconsider.

Comment 13

[Daniel Holbert [:dholbert]]

I think this should have been fixed by bug 465448's checkin -- can anyone still reproduce it?  (in mozilla-central builds after Jan 5 or in 1.9.1 builds after Jan 9)

Comment 14

[Johnny Stenback (:jst)]

This is still happening, but what's happening here is that the JS in the XUL document calls sizeToContent() from inline script in the XUL file. XUL doesn't do incremental layout, and thus there's no content to size to when it's called this early. I think this is per design, and I don't think this is something we're likely to change. Marking WONTFIX, but please reopen if I'm completely wrong here...