Closed Bug 119850 Opened 23 years ago Closed 2 years ago

Mixed wrapping data and nonwrapping data on the same line

Categories

(Core :: Layout, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 788929

People

(Reporter: timeless, Unassigned)

References

()

Details

Copying a venkman error [can't set breakpoint on inspector line because it 
has no code] to nc4 to report a bug about venkman (while trying to use venkman 
to report a bug about inspector).

vnk: setCurrentSourceProvider: [object Object]
###!!! ASSERTION: Mixed wrapping data and nonwrapping data on the same line: 
'mCurrentLine.Length() == 0', file 
f:\build\mozilla\content\base\src\nsPlainTextSerializer.cpp, line 1467

NTDLL! 77fa018c()
nsDebug::Assertion(const char * 0x02000568, const char * 0x0200054c, const char 
* 0x02000510, int 1467) line 290 + 13 bytes
nsDebug::WarnIfFalse(const char * 0x02000568, const char * 0x0200054c, const 
char * 0x02000510, int 1467) line 396 + 21 bytes
nsPlainTextSerializer::Write(const nsAString & {...}) line 1467 + 51 bytes
nsPlainTextSerializer::DoAddLeaf(int 118, const nsAString & {...}) line 956
nsPlainTextSerializer::AddLeaf(nsPlainTextSerializer * const 0x075fda24, const 
nsIParserNode & {...}) line 429
CNavDTD::AddLeaf(const nsIParserNode * 0x059de0c0) line 3802 + 25 bytes
CNavDTD::HandleEntityToken(CToken * 0x05a6ba30) line 2168 + 18 bytes
CNavDTD::HandleToken(CNavDTD * const 0x075fd1d0, CToken * 0x05a6ba30, nsIParser 
* 0x075fa0d0) line 906 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x075fd1d0, nsIParser * 0x075fa0d0, 
nsITokenizer * 0x075fd150, nsITokenObserver * 0x00000000, nsIContentSink * 
0x075fda24) line 525 + 20 bytes
nsParser::BuildModel() line 1981 + 34 bytes
nsParser::ResumeParse(int 0, int 0, int 0) line 1847 + 11 bytes
nsParser::Parse(const nsAString & {...}, void * 0x00000000, const nsAString & 
{...}, int 0, int 1, nsDTDMode eDTDMode_autodetect) line 1730 + 17 bytes
nsHTMLFormatConverter::ConvertFromHTMLToUnicode(nsHTMLFormatConverter * const 
0x075f8100, const nsAutoString & {...}, nsAutoString & {...}) line 321
nsHTMLFormatConverter::Convert(nsHTMLFormatConverter * const 0x075f8100, const 
char * 0x075fb71c, nsISupports * 0x075f80c0, unsigned int 610, const char * 
0x013fc8e8, nsISupports * * 0x0012fbfc, unsigned int * 0x0012fc04) line 253 + 
26 bytes
nsTransferable::GetTransferData(nsTransferable * const 0x075fad40, const char * 
0x013fc8e8, nsISupports * * 0x0012fbfc, unsigned int * 0x0012fc04) line 383
nsDataObj::GetText(const nsACString & {...}, tagFORMATETC & {...}, tagSTGMEDIUM 
& {...}) line 612
nsDataObj::GetData(nsDataObj * const 0x075fb580, tagFORMATETC * 0x0012fcc0, 
tagSTGMEDIUM * 0x0012fc84) line 196 + 23 bytes
OLE32! 77a8d301()
OLE32! 77a8d1d5()
OLE32! 77a5693d()
USER32! 77e12e98()
USER32! 77e139a3()
USER32! 77e1395f()
NTDLL! 77fa032f()
USER32! 77e1569d()
nsAppShell::Run(nsAppShell * const 0x004b6fa0) line 105 + 24 bytes
nsAppShellService::Run(nsAppShellService * const 0x004b3380) line 303
main1(int 1, char * * 0x00444390, nsISupports * 0x00000000) line 1264 + 32 
bytes
main(int 1, char * * 0x00444390) line 1594 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e97d08()
What is the data that is converted to plain text? 

This is because some (potentially) wrapped text has been inserted but then
something else comes along, a <pre> for instance, and inserts text that can't
wrap. Therefore a <pre> must flush the text buffer before text is inserted.
<pre> does this right now so it don't think it's a <pre> that's caused this to
happen. 


Hmm... There is also a "aString.First() == PRUnichar('>')" case that I don't
recall having seen before. It seems as a line starting with a ">" inside a span
triggers <pre>-formatted output. That must be wrong. Is that what happens for you?

("line" = chunk of text sent to the converter)


Ok. I seem to have reviewed that code (it's a fix for bug 69638) back in July. I
wonder if that's the problem. Anyway, I have to see tha data that
nsPlainTextSerializer is fed with to be able to say anything remotely wise.
Did this appear a couple of days ago? In that case it's caused by the checkin
for bug 92331 - plain text reply indenting isn't ending lines correctly with
values other than 78 chars.

Adding jfrancis to the CC. 
I've been a negligent QA so i have no idea when this started,

Clipboard that can trigger it (as heard by nc4editbox): 'de at line 196
<chrome://inspector/content/ViewerRegistry.js> contains no code at line 207
<chrome://inspector/content/ViewerRegistry.js> contains no code at line 207
Exceptions will now stop the debug target.'

Pasting the code into a blank mozilla composer page results in:
<table border="0" cellpadding="0" cellspacing="0" id="output-table">
  <tbody id="output-tbody">
    <tr class="msg" msg-type="ERROR">
      <td class="msg-data" msg-type="ERROR"><span>de at line 196<br>
      </span></td>
    </tr>
    <tr class="msg" msg-type="ERROR">
      <td class="msg-data" msg-type="ERROR"><span>&lt;<a class="venkman-link" 
target="_content" 
href="chrome://inspector/content/ViewerRegistry.js"><span><img 
class="spacer-node">
chrome://inspector/<img class="spacer-node">
content/ViewerRegistry.<img class="spacer-node">
js<img class="spacer-node">
      </span></a>&gt; contains no code at line 207<br>
      </span></td>
    </tr>
    <tr class="msg" msg-type="ERROR">
      <td class="msg-data" msg-type="ERROR"><span>&lt;<a class="venkman-link" 
target="_content" 
href="chrome://inspector/content/ViewerRegistry.js"><span><img 
class="spacer-node">
chrome://inspector/<img class="spacer-node">
content/ViewerRegistry.<img class="spacer-node">
js<img class="spacer-node">
      </span></a>&gt; contains no code at line 207<br>
      </span></td>
    </tr>
    <tr class="msg" msg-type="INFO">
      <td class="msg-data" msg-type="INFO"><span>Exceptions will now stop
the debug target.</span></td>
    </tr>
  </tbody>
</table>
Yes, that's it. Study the line:
   </span></a>&gt; contains no code at line 207<br>

It's inside a span (it was inside two span:s before the inner one ended) and the
entity &gt; will be translated to the string ">" and sent to write where it gets
treated as preformatted text and causes the assert.

Akkana, do you remember the reasoning behind the lines:
  if ((mPreFormatted && !mWrapColumn) || IsInPre()
-->   || (!mQuotesPreformatted && mSpanLevel > 0
-->       //&& Substring(aString, 0, 1) == NS_LITERAL_STRING(">"))) {
-->       && aString.First() == PRUnichar('>'))) {

The QuotesPreformatted prefs was true until last week so I don't think this code
has been active (normally). 

AFAIK the case can be removed, but as it was part of your fix for bug 69638, I
guess it's needed. In that case we need to make the test better to only be
triggered when it should be triggered.
Sorry for the delay.  I believe Joe has flipped the switch to turn off
mQuotesPreformatted, so the code is active now; or if it isn't, it will be soon.
 We do still need it.
Akkana speak truth with non-forked tonuge!
tongue? (don't worry i'm sure i make more spelling errors than you do) -- now where's that spellchecker [bug/rfe] for submittable form fields/.
i dont think anyone makes more spelling errors than me.  it's cuz i look at the 
keyboard while typing, rather than the screen.
QA Contact: chrispetersen → layout

The bug assignee didn't login in Bugzilla in the last 7 months.
:dholbert, could you have a look please?
For more information, please visit auto_nag documentation.

Assignee: bratell → nobody
Flags: needinfo?(dholbert)
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Flags: needinfo?(dholbert)
You need to log in before you can comment on or make changes to this bug.