User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168pre) Gecko/2009042005 GranParadiso/3.0.10pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124pre) Gecko/2009042005 GranParadiso/3.0.10pre
On Windows, I got reports from 2 users using the HTML Validator extension with the 3.0.10pre. With this version, and it seems with 3.0.8 pre and 3.0.9 pre, Firefox crashes when viewing the pages source.
I am the extension author.
Such problem does not happen with production builds (yet).
Steps to Reproduce:
1. Download ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla1.9.0/firefox-3.0.10pre.en-US.win32.zip
and unzip the file.
2. Start Firefox
3. Install the HTML validator (the version is not really important) 0.855 here
4. restart Firefox
5. Go to www.google.com
6; View Source -> crash
It is happening only in pre build ?
After debugging the tidySource.js file.
I found that it crashes when putting a color on the lines of the HTML source where there is a HTML error.
The procedure is called - colorizeLines.
The way this procedure works is that it changes the DOM of the HTML source of the HTML...
There is an option in the HTML validator to disable it :
- Hightlight lines with errors.
Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199pre) Gecko/2009042105 GranParadiso/3.0.10pre
1 xul.dll nsTextFrame::ClearTextRun mozilla/layout/generic/nsTextFrameThebes.cpp:3503
2 xul.dll BuildTextRunsScanner::AssignTextRun mozilla/layout/generic/nsTextFrameThebes.cpp:1835
3 xul.dll BuildTextRunsScanner::BuildTextRunForFrames mozilla/layout/generic/nsTextFrameThebes.cpp:1716
4 xul.dll BuildTextRunsScanner::FlushFrames mozilla/layout/generic/nsTextFrameThebes.cpp:1119
5 xul.dll xul.dll@0x2c1bcb
6 xul.dll xul.dll@0x2c1c54
7 xul.dll xul.dll@0x2c1c54
8 xul.dll BuildTextRuns mozilla/layout/generic/nsTextFrameThebes.cpp:1036
9 xul.dll nsTextFrame::EnsureTextRun mozilla/layout/generic/nsTextFrameThebes.cpp:1859
10 xul.dll nsTextFrame::Reflow mozilla/layout/generic/nsTextFrameThebes.cpp:5535
11 xul.dll nsLineLayout::ReflowFrame mozilla/layout/generic/nsLineLayout.cpp:859
I use your excellent extension and I now believe that my bug 489509 may be in fact a DUPlicate of this bug 489322.
Adding crashreportid keyword
> It is happening only in pre build ?
When following the steps to reproduce you provided with Firefox 3.0.9 rv:188.8.131.52 build 2009040821 (XP Pro SP3 here), I crashed (see bug 489509 for more info on this).
Using View/source view (Ctrl+U) will not crash on any/all webpages: like you say, the webpage must have errors and hightlight lines with errors option should be checked.
*** Bug 489509 has been marked as a duplicate of this bug. ***
Firefox 3.0.9 downloaded in the background and installed when I restarted. Ordinarily I think that is a brilliant thing, but this time, because of this bug, it's corrupting my ability to work.
Confirmation crash reports:
I installed the latest 0.8.5.5 version from the author's site because it's newer than the AMO version (typical) however this also caused the same crash.
Confirmed with Firefox 3.0.9 and HTML Validator 0.8.5.2 & 0.8.5.5
When viewing source, application crashes.
Need a regression range here...
Rey: Do we have contacts with the HTML Validator team? We should probably work with them on a workaround since 3.0.10 won't be for another month.
Sam, the originator of this bug is the add-on's author. His name is Marc Gueury.
I am the extension author. I am sorry but I am quite lost in what to do to avoid the flood of mails I get...
This code that cause problems in the extension was working from
Firefox 1.0 until 3.0.8. And unhappily, 3.0.9 crashes as well as 3.0.10 pre....
The bug is not in my side and the only thing I can do is to disable
the highlighting of the lines with HTML errors :/
Without better solution and due to the urgency, I have released on my website As well as on addons.mozilla.org a version 0.856 that disables this feature.
Unhappily, 0.856 is not reviewed yet in addons.mozilla.org:
DO YOU KNOW A WAY TO SPEED THE REVIEW ?
Thanks a lot,
I first found this behavior in version 3.0.8pre, maybe this information helps to track down the bug.
If somebody does a binary search of nightly builds (look in the directories ending in "-mozilla1.9.0" in the month subdirectories of http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/ ) to figure out which day the problem started, that would be likely to help. If you do this... say (1) what platform you were testing, (2) which build was the last one without the problem, and (3) which build was the first one with the problem. (And, if you want to be even more precise, you can give the SourceStamp line from the application.ini file along with (2) and (3).)
3.0.8pre became 3.0.9... There weren't really "pre" builds of what became the
actual 3.0.8 release, it was an emergency release based off the 3.0.7 release
with a couple of fixes. The "3.0.8" we were working on was renamed to 3.0.9 to
make room for that release.
But that does pin the time frame down to before the rename.
It's a new topcrash, too. Hard to believe all those people are using HTML Validator.
@Daniel Veditz - HTML Tidy it's the best thing created for webmasters!
thanks Marc Gueury, but you really need to solve this thing, I'll turn back to 3.0.8, i can't even browse a website without that addon ....
I haven't gone back for a full regression range yet, but I'd guess bug 431260 or bug 444027, both of which landed in the cycle. If someone can verify by checking the February 26 build to the February 27 build, that'd be great.
(In reply to comment #10)
> ...Without better solution and due to the urgency, I have released on my website
> As well as on addons.mozilla.org a version 0.856 that disables this feature.
> Unhappily, 0.856 is not reviewed yet in addons.mozilla.org:
> > https://addons.mozilla.org/en-US/firefox/addon/249
> DO YOU KNOW A WAY TO SPEED THE REVIEW ?
> Thanks a lot,
I've pushed your update through.
I have chosen to downgrade Firefox, i prefer having HTML Validator rather than FF 3.0.9. Hope u solve this soon. THX!
(In reply to comment #16)
> I haven't gone back for a full regression range yet, but I'd guess bug 431260
> or bug 444027, both of which landed in the cycle. If someone can verify by
> checking the February 26 build to the February 27 build, that'd be great.
That range is indeed true.
Andrei, if you get the new version of the validator, it doesn't crash...
Doesn't crash in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206pre) Gecko/2009022606 GranParadiso/3.0.8pre (.NET CLR 3.5.30729).
Crashes in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11pre) Gecko/2009022606 GranParadiso/3.0.8pre (.NET CLR 3.5.30729).
Er... it crashes in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168pre) Gecko/2009022706 GranParadiso/3.0.8pre (.NET CLR 3.5.30729).
mgueury: can you extract the code from tidySource.js into a testcase which crashes by itself?
I can't reproduce this in a debug build on Linux, but I *can* reproduce it 100% reliably in an optimized build. (using HTML Validator version 0.8.5.4 from the download URL in comment 0)
I tried viewing source of google.com and also the default Firefox start pages, http://www.mozilla.org/projects/granparadiso/ and http://www.google.com/firefox?client=firefox-a&rls=org.mozilla:en-US:official
Crash reports links below. They're all crashes at random addresses while inside of nsTextFrame::ClearTextRun() (usually 0xaf******). In the third Firefox3.0.9 crash below, the random address actually appears to map to an address in one of my font files, "DejaVuSans-Bold.ttf@0x61f1e".
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/2009040820 Firefox/3.0.9
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199pre) Gecko/2009042204 GranParadiso/3.0.10pre
*** Bug 489568 has been marked as a duplicate of this bug. ***
Firefox updated itself to 3.0.9 and i had to get new version. I don't notice any diffrence though..
FWIW, I think we have a fix for this in bug 489647. Stay tuned...
Created attachment 374229 [details]
Here's a reduced testcase that reproduces the bug under Linux, when doing a View-Source with HTML Validator 0.854 installed in Firefox 3.0.9.
*** Bug 489783 has been marked as a duplicate of this bug. ***
*** Bug 489790 has been marked as a duplicate of this bug. ***
*** Bug 489621 has been marked as a duplicate of this bug. ***
@Daniel Holbert - oh yea .... more restricted pages ... :|
Assigning this to dholbert since he has a fix.
This will be fixed in a soon-coming Firefox 3.0.10 release.
The fix in bug 489647 has landed.
This turned out to be a regression from bug 431260
Sweet! So this will be in 3.0.10?
Verified fixed on Linux in 188.8.131.52 with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/2009042315 Firefox/3.0.10.
I will mark it verified220.127.116.11 when I can check on Windows as well.
Checked on Windows with version Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:18.104.22.168) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
Validator version 0.8.5.2 since in 0.8.5.6 the "mark line" feature seems to be completely disabled although there is a check box...
All clear ;-)
Verified on Windows XP: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729).
Marc: This problem is now fixed in Firefox 3.0.10, which is being released today, specifically for this crash. It typically takes 5-8 days for the bulk of Firefox users to upgrade. You can probably return your extension to the normal, fully functional version in a few days. Thanks for reporting the problem!
Thanks a lot your work. I will release a new version re-enabling the line highlighting in the next days.
Hey ... common Marc, the 3.0.10 it has been released. Why don't you make the update? I downgraded to 0.855 and everything works fine :) you should to the same
Verified for 126.96.36.199 as well with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52pre) Gecko/2009051404 GranParadiso/3.0.11pre.