From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.6+) Gecko/20011218 BuildID: 2001121822 On http://news.bbc.co.uk in both the "sport news" and the "TOP STORIES AROUND THE UK" boxes the text runs off to the right and overwrites the next column. Reproducible: Always Steps to Reproduce: 1. Go to http://news.bbc.co.uk 2. Scroll down to "Sport news" 3. Look at text to see it run off to the right over the next column's text Actual Results: Text overwriting other text Expected Results: The text should be contained within the text boxes This does not appear to happen using the same nightly build for win2k. The system it was tested on is running solaris 2.8

I can confirm this bug with Sparc Solaris 7 build 2001121922. This bug appears when I go to the site. If I download the page and open it locally (without images, etc.) the bug does not appear. A problem with the way the images are affecting the table layout?

This might not be that useful, since bug doesn't show up if page is opened away from the site.

I also see this on Linux (PC), with a recent trunk build, occurring on the attached testcase.

The attachment is in fact considerably worse for me (2001121922 solaris 2.8) than the original web page. The text from the first column overruns the second column and in places the line below. In the third column there are overruns and in places only parts of characters are displayed. Basically there are text overruns and overwrites all over. I "checked" it with IE 5 which seems to render it just fine.

On Mac builds I see it reliably in the testcase, and I've been seeing it on the BBC News site itself for the past few weeks. It's intermittent between reloads: sometimes several block elements will have a font size which is too large, sometimes just a few elements. I'd think it would have something to do with exactly when the style sheet was getting loaded, except that the attached testcase 404s the style sheet but the problem still occurs. For each oversized block element, it will be properly vertically sized, but about half the time, line breaks will be inserted as if the smaller font size was being used. This makes it overflow horizontally and leak into the next column.

Just noticed this page: http://www.wired.com/news/business/0,1367,49719-2,00.html This seems to have the same problem (linux 2002012308). That's two; get enough of these and we might get this fixed :)

Just another note: saving this page, using the new complete-save, rather than the page-only save that is mentioned here (http://bugzilla.mozilla.org/show_bug.cgi?id=116273#c1) ...I also *don't* see this behaviour. Also, here the end of the buggy text appears to be in either the 'IN DEPTH' or 'TALKING POINT', near the top of the right-hand column. The start is the text below each of 'AFRICA', 'AMERICAS', etc.

Another wired.com page which does the same: http://www.wired.com/news/technology/0,1282,49717,00.html But not all pages do, eg. this does *not*: http://www.wired.com/news/technology/0,1282,50037,00.html [linux 2002012508]

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

I notice that this bug has been marked as a 1.2 milestone. If 1.0 is to be a "stable, long-lived branch" as stated in http://www.mozilla.org/roadmap/mozilla-1.0.html then shouldn't obvious problems like not being able to read all the text on one of the world's most visited web sites be a 1.0 milestone? I know this is simply a matter of priorities but I suggest this should be a high one.

I'm seeing this too. I think it should be a 1.0 bug. Also is bug #122533 and/or bug #122536 the same problem?

One thing I noticed is that clicking "Reload" fixes some of the problems with the BBC site. This tells me this is a Mozilla problem (at least partially) and as a layout issue should be fixed by v1.0.

I've noticed that the BBC are now putting a "Transitional" DOCTYPE line on a fair proportion, but unfortunately not all, of the pages. From fairly extensive surfing of the site yesterday it would seem, tentatively, that the problems have "gone away". It would be nice to know from the BBC if in fact they have changed anything which could have fixed this bug. I am e-mailling them to invite them to join the Cc: list.

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

I just noticed that a similar 'large font' effect appears to be evident at: http://news.bbc.co.uk/hi/english/sci/tech/newsid_1816000/1816860.stm This has the same characteristic of disappearing when the page is saved/loaded locally using the 'save complete page' feature. This perhaps provides a more permanent test-case URL, since AFAIK the articles are archived (cf the front page which I assume is completely dynamic). Also it might be useful to note that if selecting (using the mouse) the overly large text, then the (blue) selection regions are smaller than the text size (on the original URL). Selecting the text in the right-hand column allows this text to be read, where normally it is 'over-typed' by the large text, and deselecting leaves that text rendered properly; but clicking a link appears to re-render the entire page, leaving the 'overtyped' mess in the right-hand column. However these selection problems *don't* occur with the URL given above, so perhaps this might hint at a different cause of the problem (if they really are related).

OK: Here's another example of the possibly-related problem from http://bugzilla.mozilla.org/show_bug.cgi?id=116273#c18: http://news.bbc.co.uk/hi/english/sci/tech/newsid_1818000/1818790.stm Interestingly this shows the font reducing size (to the right value?) when reaching an image, as in the other URL. I also remembered seeing similar problems to this in 4.x (under windows), where font-size would change mid-way through a (news.bbc.co.uk) page for no reason; in fact this new example came to light while using said browser...

Also effects http://www.telegraph.co.uk

Is http://bugzilla.mozilla.org/show_bug.cgi?id=125056 a duplicate of this bug? (that title is more accurate, but this has more info?)

Bug 125056 looks similar to this one, but I note there is no actual (visible) overflowing ocurring. I also note that it rates a P1 ;-)

Gyles wrote: > Bug 125056 looks similar to this one, but I note there is no actual (visible) > overflowing ocurring. Well my comments #9 and #11 actually point to wired pages; while that doesn't imply that the wired.com behaviour is associated with the same problem exactly, it has the same effects: overly-large font which causes a paragraph to overflow to the right - in the case of wired.com, *under* a banner graphic. What do you mean by no visible overflowing? It certainly seems to be on the screenshot of that bug? >I also note that it rates a P1 ;-) Well yes; even if this *doesn't* qualify as the same bug, it is a similar layout problem, so IMO should likely have the same priority?

*Surely* as this is such a visible bug this ought to be fixed by 1.0?

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

This bug is also a regression since it didn't occur in 0.9.7 It would be worth stepping through nightly builds since 0.9.7 to see when this behaviour started. It *is* very bad and it is embarassing to exhibit this behaviour on a top site like the BBC. I would hate this to be in 1.0.

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

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

I have a (CVS) build labelled thus: Mozilla 0.9.8+ Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.8+) Gecko/20020204 This shows the problem. That bounds the date at the other end from Ben's comment 26. I really feel this is a 1.0 bug.

ok, I checked two builds on windows 2000: this *does not* occur on milestone 0.9.7 this *does* occur on milestone 0.9.8 So that narrows it down (a little) further to the range 21 Dec 2001 - Feb 4 2002 Unfortunately it appears that nightlies on ftp.mozilla.org don't go back this far, so I can't narrow this any further that way. I guess the thing to do would be to do a build from CVS specifying the code as was on, say, Jan 14. Does anyone know how to specify this with the mozilla CVS setup?

I have the nightly build ID 2002010209 on Windows XP and it *does* occur in that build. I also have the nightly build ID 2001122003 and it also *does* occur in that build. This suggests that it was something that didn't make it into the 0.9.7 milestone branch but was in the trunk. I've tested with nightly build ID 2001112508 and it *does not* occur in that build. Narrows the date down to 25 Nov 2001 - 20 Dec 2001 on checkins to the trunk

ok, ignore comment 30, I forgot about branching before release 0.9.7 branched from the trunk on 14 Dec. Since it doesn't exhibit this problem, it's probably safe to assume that ian's findings from comment 31 narrow the culprit down to: trunk checkins between 14 Dec and 20 Dec

What about (uninformed guess): 12/14/2000 22:09 attinasi%netscape.com mozilla/layout/base/src/nsStyleContext.cpp Turned on Style Context Data Sharing. [bug 39618] Maybe someone could try this (from 39618): To turn off the style context data sharing, set an environment variable like 'moz_disable_style_sharing=1' - very handy for testing for regressions.

The style context sharing is long since gone (since May 2001). Instead, style data sharing is used... This is almost certainly the same bug as bug 125056 (the bbc.co.uk page has a <link> element at the end before </body>). Marking dependency

Sure, scratch comment 33; March is a bit late to be thinking that last year was 2000.

Huh? I never touched the dependancies.

Updating dependency - bug 125056 was duplicated to 129350.

This is fixed by the patch on bug 129350. *** This bug has been marked as a duplicate of 129350 ***

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

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

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

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