Last Comment Bug 504565 - jsdIScript baseLineNumber incorrect
: jsdIScript baseLineNumber incorrect
Status: NEW
[firebug-p2]
:
Product: Core
Classification: Components
Component: HTML: Parser (show other bugs)
: 1.9.1 Branch
: x86 Windows XP
: -- normal with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 483015
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-16 07:42 PDT by John J. Barton
Modified: 2011-01-06 09:19 PST (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description John J. Barton 2009-07-16 07:42:42 PDT
Here is a new case where the base line numbers in jsdIScript are incorrect:
http://code.google.com/p/fbug/source/browse/tests/issues/2046/issue2046.htm

I think you can get a copy this way:
svn checkout http://fbug.googlecode.com/svn/tests/issues/2046/issue2046.htm

The original report was on 3.0.10, but I confirmed it on
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
Comment 1 John J. Barton 2009-07-16 07:46:47 PDT
Bug 488730 fixed seemingly similar issues, so it may be a good one to read.
Comment 2 James Ross 2009-07-16 08:40:41 PDT
This took me a while to reproduce, but I can (using JSD/Venkman) confirm I get baseLineNumber=25 with the exact file in SVN.

The issue (and why it was hard for me to reproduce initially) seems to be related to the inconsistent line endings in the file (a mixture of Windows and Unix), as I cannot reproduce the problem when I force them all to be Windows or all Unix.

Asssuming the file has Windows line ends generally, there are exactly 14 Unix line ends before the <script> tag, which is the error in line number (39 is the correct baseLineNumber). I don't like coincidences like that.
Comment 3 James Ross 2009-07-16 08:42:08 PDT
I did the tests on Venkman 0.9.87.4 on Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1) Gecko/20090624 Firefox/3.5.
Comment 4 Blake Kaplan (:mrbkap) (in and out until 7-14) 2009-07-16 16:49:03 PDT
This is a bug in CTextToken::ConsumeParsedCharacterData. It simply counts the number of newlines in the text or style node, which ignores stray carriage returns. Unlike bug 488730, there isn't a really simple fix here without rewriting the way that we scan for </script>. I know that this is nice to have, but honestly, we might have to wait for the HTML5 parser to fix this.
Comment 5 John J. Barton 2009-07-16 16:59:33 PDT
Do you think we could rationally 'fix' the lines on Firebug side? I already have code to shift the line offsets. If I have an algorithm that works and more important doe not break on normal sources, it could be a working solution until the new parser.
  1) only HTML files?
  2) delete CR in what cases?
Comment 6 Henri Sivonen (:hsivonen) 2009-07-17 02:32:51 PDT
The HTML5 parser bug for line numbers is bug 483015. However, while implementing line numbers, I noticed that the expectations on how line numbers work for document.written content weren't documented anywhere.
Comment 7 Jan Honza Odvarko [:Honza] 2010-11-11 05:14:39 PST
Here is another test case (all line endings set to Windows)
http://code.google.com/p/fbug/source/browse/tests/issues/2046/issue2046-2.html

Online version is here:
http://getfirebug.com/tests/issues/2046/issue2046-2.html

The break in the file happens on line 7 instead of line 13.

If the try-catch block is inserted into another block like as follows:

{ try-catch }

it works.

Is this related to this report?
Honza

Note You need to log in before you can comment on or make changes to this bug.