Oversized text overflows blocks on BBC News site




17 years ago
16 years ago


(Reporter: raphael, Assigned: attinasi)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(4 attachments)



17 years ago
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

Comment 1

17 years ago
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?
Severity: normal → trivial
Ever confirmed: true

Comment 2

17 years ago
Created attachment 62405 [details]
The page that shows the bug

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.
Keywords: testcase
OS: Solaris → All
Hardware: Sun → All

Comment 4

17 years ago
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.

Comment 5

17 years ago
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.
Severity: trivial → normal
Summary: text overruns and writes over text in next column → Oversized text overflows blocks on BBC News site

Comment 6

17 years ago
Created attachment 64287 [details]
news.bbc.co.uk as rendered in MSIE

Comment 7

17 years ago
Created attachment 64288 [details]
news.bbc.co.uk as rendered on 1st load in Mozilla

Comment 8

17 years ago
Created attachment 64289 [details]
news.bbc.co.uk as rendered on 2nd load in Mozilla

Comment 9

17 years ago
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 :)

Comment 10

17 years ago
Just another note: saving this page, using the new complete-save, rather than
the page-only save that is mentioned here
...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.


17 years ago
Target Milestone: --- → mozilla1.2

Comment 11

17 years ago
Another wired.com page which does the same:
But not all pages do, eg. this does *not*:
[linux 2002012508]

Comment 12

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

Comment 13

17 years ago
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.

Comment 14

17 years ago
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?

Comment 15

17 years ago
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.

Comment 16

17 years ago
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.

Comment 17

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

Comment 18

17 years ago
I just noticed that a similar 'large font' effect appears to be evident at:

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

Comment 19

17 years ago
OK: Here's another example of the possibly-related problem from

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...

Comment 20

17 years ago
Also effects http://www.telegraph.co.uk

Comment 21

17 years ago
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?)

Comment 22

17 years ago
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 ;-)

Comment 23

17 years ago
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?

Comment 24

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

Comment 25

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

Comment 26

17 years ago
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.

Comment 27

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

Comment 28

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

Comment 29

17 years ago
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.

Comment 30

17 years ago
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?

Comment 31

17 years ago
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

Comment 32

17 years ago
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

Comment 33

17 years ago
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
Depends on: 125056

Comment 35

17 years ago
Sure, scratch comment 33; March is a bit late to be thinking that last year was
No longer depends on: 125056

Comment 36

17 years ago
Huh?  I never touched the dependancies.
Depends on: 125056


17 years ago
Blocks: 92997


17 years ago
Keywords: testcase → mozilla1.0, nsbeta1

Comment 37

17 years ago
Updating dependency - bug 125056 was duplicated to 129350.
Depends on: 129350
No longer depends on: 125056
This is fixed by the patch on bug 129350.

*** This bug has been marked as a duplicate of 129350 ***
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
*** 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. ***
You need to log in before you can comment on or make changes to this bug.