Closed Bug 44432 Opened 24 years ago Closed 24 years ago

BBC News articles render with doubled content

Categories

(Core :: DOM: HTML Parser, defect, P3)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: cks+mozilla, Assigned: harishd)

References

(
URL
)

Details

Attachments

(2 files)

testcase
8.80 KB, text/html
Details
testcase that can be used as a local file
43.04 KB, text/html
Details 
Build ID: a current CVS build.

 Many articles on the BBC News website now appear to render with a second
copy of the article below the original copy. Sometimes, for no apparent
reason, this doesn't happen. I believe that there may be other layout
glitches; certainly the font styling seems to have changed from what I
would expect and what I saw before.

 This problem has appeared since last night's CVS build. If one does a
File | Edit Page, the editor displays the page un-doubled (although the
font oddness is still there).

Reproduction:
- go to http://news.bbc.co.uk/
- pick a news article
- scroll down. most of the time you'll find another copy of the article
  below the first one.
Do you still see this?  I am using 2000070220 on Linux and I cannot reproduce
it.
I can't reproduce this either, using CVS from noon PDT 07/03. Marking WFM.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
 This seems to have vanished in today's CVS build. (There are whacky
font look problems, which I will file as a separate bug.)

Chris, can you check this page? http://www.snopes.com/spoons/spoons.htm
It seems to be the problem you mention (same build as before.) Still can't get
the BBC pages to do it, however. Reopening for now, hopefully you can confirm
yes or no.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
 Unfortunately, the build that has the problems with doubled BBC web pages
shows nothing wrong on http://www.snopes.com/spoons/spoons.htm.

Confirmed on Linux 2000070308.

Oddly enough, I wget'ed this page and was unable to reproduce from a local
file:// address.

w3.org's validator comes up with lots of ickyness, I'm not sure if this is
related though.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Forgot to CC: myself.
Pierre, can you please triage.
Assignee: clayton → pierre
I cannot repro this on a fresh Linux or WinNT build...
I still see this on 2000070708, Linux. Clean ~/.mozilla and everything.
I still see this with the 2000-07-08 08:00 build at e.g.:
http://news.bbc.co.uk/hi/english/sci/tech/newsid_823000/823501.stm
so marking OS as 'All'.

Note that the whole of the content is not repeated, just that inside the first 
big <table> which spans most of the document (lines 29-398 on the url above).

The <FORM ACTION="/scripts/query.idq" METHOD=GET> between lines 276-84 isn't at 
all properly nested, which shows up on the W3C validator.  There's also a great 
chunk of javascript in the table, but I'm not sure what the problem there would 
be.

I, too, can't reproduce the bug from a saved copy of the page.

As for the font issue, it looks like the style sheet isn't being applied.  
Perhaps for compatibility because the whole page is in a table?

Anyway, I now have a tidied-up version of the page if that would help anybody.
OS: Linux → All
Alistair Vining, you forgot to mention what OS you tested on to prove that this
is an OS: All bug. We need to see it reproduced on at least three OSes (Win,
Linux, Mac) before marking all.

I've tried using a local copy of a completely tidy'ed and valid version of the
page and the problem doesn't show up. As I previously mentioned, I also tried
using an exact duplicate wget'ed from the site.

Is this Networking or something?
Apologies, I was using Win98 SE.  That's All OS on the PC platform ;)

I agree it doesn't work locally, but if I put a copy of the page up on my 
website it does recur.
http://www.heimdallr.u-net.com/mozilla/killer-seaweed-moz/823501.html

I take that back, it recurs intermittently.  It seems to be related to the cache 
- clear the disk cache and the next reload will show the bug.  So it doesn't 
seem to show however the page is loaded from disk.  So Networking...?
HOORAY!!! Don't ask me how I found out but to reproduce the bug, all you need is:
- a loose.dtd or strict.dtd DOCTYPE.
- a <MAP> in the <HEAD> (even an empty <MAP> is fine).
- a file larger than a certain size: around 9400 bytes on the web or around 44K 
for a local file (even tons of HTML comments is fine).

As Alistair pointed out, to see the bug you need to reload a fresh copy of the 
file each time. For local files, it means that you always have to clear the disk 
cache. For remote files, select "Compare the page in the cache to the page on the 
network -> Every time I view the page" in the prefs and it should do the trick 
most of the time. When in doubt, clear the disk cache manually before doing a 
reload.

Surprisingly, I could not reproduce it on the Mac at all.

I understand that this bug is related in some way to the Network library and the 
different buffer sizes depending on the transport methods however too many things 
point to the Parser so I'm reassigning it to Harish.

Also, it would be a good idea to test whether this bug is yet another regression 
introduced between 06/28 and 06/30.

I'm going to attach a testcase. If it doesn't show the bug when browsed on 
Bugzilla because of differences in network configurations with what I have been 
using until now, I may have a attach a bigger file.
Assignee: pierre → harishd
Component: Layout → Parser
Attached file testcase — 

    
    

    
  
The testcase shows the problem on my machine (Win98, build 2000/07/14) when I 
click on the link above.

I'm going to attach a similar (just bigger) testcase that you can store as a 
local file to reproduce the bug. But then don't forget to clear the cache each 
time.


    
    

    
  
Hmm, not able to reproduce at all.  Pierre, since you're seeing the problem (
which I think could be network related ) could you please attach the content model
of the test case?  It would give us some more direction. Thanx
Status: NEW → ASSIGNED

    
    

    
  
I can't dump the content model: the bug can't be reproduced with Viewer.

To reproduce:
- Download the lastest daily build (2000-07-21).
- Launch and clear the Disk Cache.
- Go to http://bugzilla.mozilla.org/showattachment.cgi?attach_id=11676 (it's the 
"testcase that can be used as a local file": use it as a remote file and you are 
almost guaranteed to see the problem).

If you still can't reproduce it, try the same thing from home.


    
    

    
  
Chris, Eliot, Alistair: if you can reproduce the bug with Viewer in your debug 
builds, and using one of my 2 testcases, could you please attach the content 
model?


    
    

    
  
Pierre - Can you point me to somewhere about how to dump a content model? I'm
not familiar with that and no one on #mozillazine knew either.

    
    

    
  

*** This bug has been marked as a duplicate of 44759 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE

    
    

    
  
Reopening... Harish, you can't close as dup a bug that you can't reproduce. If 
you want, you can reassign it to me after you check in the fix for bug 44759.

Eliot: Viewer has a Dump Content menu command.

Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

    
    

    
  
Sorry!.  Pierre, could you apply the patch in 44759 and verify if this bug goes 
away. Thanx
Status: REOPENED → ASSIGNED

    
    

    
  
Harish, big problem: I can only reproduce this problem at home where I have Win98 
running on a Macintosh with VirtualPC. I tried at the office yesterday with both 
a debug build from a fresh pull and the latest daily build but could not 
reproduce it. I tried again at home with today's build (2000-07-26-08) and the 
bug is still there with the 2 testcases above.

Since it is probably related to conditions inside the network layers, could you 
try to reproduce it at the office on a Win98 instead of WinNT, and if possible 
ona slow machine? I'm afraid I won't be able to investigate any further: it's not 
realistic to install the devlopment tools and build a tree on the configuration I 
have at home.

EVERYBODY (Chris, Eliot, Al): Do you have a debug build? Can you reproduce the 
bug with it? Clear the cache and go to the 2 testcases:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=11675
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=11676


    
    

    
  
Harish, please have a look at bug 46167, I think that is a dup of this and it is
reproduceable on my WinNT system, every time I've tried so far, if you think it's
dup of this bug then please mark as such.

    
    

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

    
    

    
  
Shoot,  bug 46167 is not a dup of this ( there's one other bug ).

    
    

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

    
    

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

    
    

    
  
I can neither reproduce the problem on this bug nor on the dups. Marking 
WORKSFORME.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME

    
    

    
  
Verified as WORKSFORME on Linux 2000080804.

I, too, checked all the testcases and various links on BBC news.

Was that magic or did a specific patch get put in for this issue?
Status: RESOLVED → VERIFIED

    
    

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

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: