21189 - [PP]First document node gets duplicate with timer-based notifications on

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Simon Fraser [no longer active]]

With the timer-based content sink notifications on, I see that on some pages, the
first node in the document gets duplicated. With the URL above, I see

Internal linksInternal links

Editor
...etc.

Comment 1

[Simon Fraser [no longer active]]

Turning off the content timer pref fixes the problem.

Comment 2

[vidur (gone)]

In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.

Comment 3

[vidur (gone)]

Simon, I can't seem to reproduce this one on Windows with the default interval
(1 second). If this still happens for you, please reopen and provide your timer
values.

Comment 4

[Simon Fraser [no longer active]]

I see the duplicated node with a wide range of timer prefs, as long as
"content.notify.ontimer" is on.

Comment 5

[Simon Fraser [no longer active]]

Still a problem.

Comment 6

[Simon Fraser [no longer active]]

This appears to be Mac-only. Hrrmm.

Comment 7

[troy]

*** Bug 21370 has been marked as a duplicate of this bug. ***

Comment 8

[Dawn Endico]

I've noticed this happen to me three different times on linux. Each time was
on the startup page (http://www.mozilla.org/). Twice it happened on the first
run after a new compile and the other time was the first run after installing
a new daily build. Each time a different link was repeated. Is the first node
in the document going to be different each time its loaded? I don't think the
web page changed. see bug 21370  for a screen shot.

Comment 9

[troy]

*** Bug 21384 has been marked as a duplicate of this bug. ***

Comment 10

[Chris Petersen]

Attachment: The first element in body gets duplicated

Comment 11

[vidur (gone)]

I can't reproduce on my machine with any of the test cases. If anyone with a
debug build on their machine can reproduce this consistently, please let me
know.

Comment 12

[Chris Petersen]

I added PP to summary since this appears to only happen on Mac. I have not been
able to reproduce this problem on Win 98 or Redhat 6.0.

Comment 13

[Dawn Endico]

Are you sure this should be PP? As I said, this happens to me on linux
(RH6.1). And never with the first element.

Comment 14

[Simon Fraser [no longer active]]

Here's a diff: note LL_CMP changes, which work around an NSPR bug on compilers
which don't have long long support enabled (bug to be filed).

Index: nsHTMLContentSink.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/html/document/src/nsHTMLContentSink.cpp,v
retrieving revision 3.285
diff -r3.285 nsHTMLContentSink.cpp
1860a1861,1863
>
>         mTextLength = 0;
> 		    didFlush = PR_TRUE;
1892a1896,1898
> 		    mTextLength = 0;
>     		didFlush = PR_TRUE;
>
1896,1897d1901
<     mTextLength = 0;
<     didFlush = PR_TRUE;
2224c2228
<       if (LL_CMP(diff, >=, interval)) {
---
>       if (LL_CMP(diff, >, interval)) {
3756c3760
<   if (LL_CMP(diff, >=, interval)) {
---
>   if (LL_CMP(diff, >, interval)) {

Comment 15

[Simon Fraser [no longer active]]

Fix checked in.

Comment 16

[Brendan Eich [:brendan]]

I designed LL_CMP back in NSPR 1.0 daze to work only for < and >, and commented
that fact.  It seems my comments were removed -- not that they would do enough
good!  Anyway, the efficiency win is enough to make this restriction on LL_CMP a
feature; but it does need to be documented and checked.

In hindsight, I should have purveyed just LL_LT and LL_GT, so no one would fall
into the trap of passing <= or >= (of course, no one pases == or * or % or ...;
you have to read the source before you use an ALL_CAPS macro, to be sure you are
using it correctly).

wtc, you want a bug asking for a comment, if not LL_LT and LL_GT macros and a
deprecated, underlying LL_CMP?

/be

Comment 17

[Wan-Teh Chang]

so for performance reasons, you don't want me to fix
LL_CMP so that you can pass <= or >= to it?

Comment 18

[Simon Fraser [no longer active]]

Note: bug 21428 has been filed on the LL_CMP issue. Please take that discusson
there.

Comment 19

[troy]

*** Bug 21333 has been marked as a duplicate of this bug. ***

Comment 20

[troy]

*** Bug 21333 has been marked as a duplicate of this bug. ***

Comment 21

[troy]

*** Bug 21513 has been marked as a duplicate of this bug. ***

Comment 22

[Chris Petersen]

Fixed in the Dec 13th build (1999121314).