Closed Bug 292279 Opened 18 years ago Closed 17 years ago
overly large iframe height or width cause crash
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050421 Firefox/1.0.3 (Debian package 1.0.3-2) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050421 Firefox/1.0.3 (Debian package 1.0.3-2) Either of the following two examples, contained in a webpage, will cause an immediate crash of Mozilla or Firefox. <iframe width="33333333"> <iframe height="33333333"> Reproducible: Always Steps to Reproduce: 1. Open browser 2. Navigate to sample page http://www.steve.org.uk/firefox/firefox-crash5.html 3. Browser crashes Actual Results: Browser exits with a segmentation fault on Linux. Expected Results: Displayed a page / Not crashed
Added blocker on 264944.
Confirmed as fixed in the trunk builds of both Mozilla & Firefox.
I couldn't get either example to crash on official 1.0.3 *windows*, and couldn't load the linked page. I wonder what unknown collection of patches Debian ships with, or if this is a general Linux-only crash.
Component: General → Layout
OS: All → Linux
Product: Mozilla Application Suite → Core
Version: unspecified → 1.7 Branch
I initially thought this might be a dupe of bug 265027 or bug 265084 since those are fixed on the trunk, but those crashed on windows and I don't crash using 1.0.3 Can someone confirm this on Linux?
The 1.0.3 Mozilla.org tarball release doesn't crash for me on Linux.... Steve, could you possibly test a Mozilla.org build on your setup?
Does this need to be security sensitive?
(In reply to comment #5) > The 1.0.3 Mozilla.org tarball release doesn't crash for me on Linux.... Steve, > could you possibly test a Mozilla.org build on your setup? Tested, the mozilla.org build does not crash on the URL given, but does crash on this: http://www.steve.org.uk/firefox/firefox-crash4.html Ditto for Mozilla v1.7.7 - crashes on #4, but not on #5. My Debian installed packages crash on both, hence my only giving the one URL in my initial report.
(In reply to comment #6) > Does this need to be security sensitive? Anybody who believes strongly that it shouldn't be may remove this flag - I assume 'remote crash == sensitive'. Hopefully the comment #7 will lead to others confirming the bug.
Most remote crashes are not security sensitive.
Well, I can reproduce the crash with a branch 1.0.3 build on the testcase in comment 7. Talkback doesn't come up (though it's installed and enabled, and core _is_ dumped). My attempt to build a 1.0.3 Firefox debug build failed utterly with: error: file '/home/bzbarsky/mozilla/aviary-branch/mozilla/toolkit/locales/en-US/chrome/necko/contents.rdf' doesn't exist at /home/bzbarsky/mozilla/aviary-branch/mozilla/config/make-jars.pl line 418. There's no toolkit/locales/en-US/chrome/necko/contents.rdf file, of course, and according to bonsai there should be nothing in that directory at all (it's all in Attic), though I did end up with the other 3 files in that Attic pulled somehow, reproducibly, when pulling from the AVIARY_1_0_1_20050124_BRANCH tag.
Looks like this got fixed on trunk between 2004-10-11-08 and 2004-10-12-07. Probably by widget change caching? Which means the underlying issue could still be there....
On the aviary branch the 3 necko locale files are correct: http://lxr.mozilla.org/aviary101branch/source/toolkit/locales/en-US/chrome/necko/ necko's contents.rdf should come from the toolkit/locales/generic sub-tree: http://lxr.mozilla.org/aviary101branch/source/toolkit/locales/jar.mn#80
*** This bug has been marked as a duplicate of 303433 ***
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.