Closed Bug 116273 Opened 23 years ago Closed 22 years ago

Oversized text overflows blocks on BBC News site

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 129350
Milestone:
mozilla1.2alpha

People

(Reporter: raphael, Assigned: attinasi)

References

(
URL
)

Details

Attachments

(4 files)

The page that shows the bug
41.52 KB, text/html
Details
news.bbc.co.uk as rendered in MSIE
33.63 KB, image/jpeg
Details
news.bbc.co.uk as rendered on 1st load in Mozilla
36.84 KB, image/jpeg
Details
news.bbc.co.uk as rendered on 2nd load in Mozilla
35.80 KB, image/jpeg
Details 
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?
Severity: normal → trivial
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
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.
Severity: trivial → normal
Summary: text overruns and writes over text in next column → Oversized text overflows blocks on BBC News site
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.
Target Milestone: --- → mozilla1.2
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
Depends on: 125056
Sure, scratch comment 33; March is a bit late to be thinking that last year was
2000.
No longer depends on: 125056
Huh?  I never touched the dependancies.
Depends on: 125056
Blocks: advocacybugs
Keywords: testcase → mozilla1.0, nsbeta1
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 ***
Status: NEW → RESOLVED
Closed: 22 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.

Attachment

General

Creator:
Created:
Updated:
Size: