146851 - aftonbladet.se - Text sometimes crosses the border on the page and a reload can cure it

Status: VERIFIED FIXED

(Tech Evangelism Graveyard :: Other, defect, P3)

Description

[André Dahlqvist]

The subject is very vague, but that is because this bug only happens sometimes,
and it is therefore hard to figure out what is wrong. Sometimes, but far from
always, the main page at aftonbladet.se is layed out badly, with text crossing
the border that surrounds it. On these occasions it often helps to reload the
page, or to leave it and then go back to it right after.

I will attach two screenshot that shows first how the bad layout can look, and
how the page looks after a reload just seconds later.

Comment 1

[André Dahlqvist]

Attachment: This is how it can look when layed out badly. Notice the text that overlaps the border.

Comment 2

[André Dahlqvist]

Attachment: Screenshot of the same page after a reload.

Comment 3

[André Dahlqvist]

I should add that I have been seeing this bug on this page for as long as I can
remember with mozilla. The screenshot was taken with a build from 2002-05-23-01.

Comment 4

[André Dahlqvist]

I can also reproduce this if I save the page locally and load it in mozilla.

Comment 5

[R.K.Aa.]

repeatedly reported - and repeatedly resolved as wfm or even invalid (?),
this is a bug that comes and goes:
layout problem at same site reported in:
bug 62091, bug 100473, bug 134091, bug 137927

Comment 6

[André Dahlqvist]

> repeatedly reported - and repeatedly resolved as wfm or even invalid (?),

That's interesting. It seams like the problem has never really been investigated
throughly, just resolved because a few people can't see the problem immediately.

Like I said: this happens just once in a while, but is NOT related to a change
on the website itself. A reload often cures it. There IS something fishy in
Mozilla that causes this. To reproduce it you basically need to surf to
aftonbladet.se once in a while, and eventually it will happen to you.

Aftonbladet.se is the most visited site in sweden with 3.6 million unique hits
per month (25 million hits in total), so this is a rather major site.

When this happens it looks as if mozilla doesn't do that last bit of correction
to the layout that it normally does. It normally moves things around a bit as it
renderes a page, but on aftonbladet.se it sometimes doesn't do that last correction.

A reproducable testcase is basically impossible to find. Some developer just
needs to place aftonbladet.se in their daily browse path:-)

Comment 7

[Laura Krietemeyer]

Changing QA Contact

Comment 8

[Gustav Broberg]

I can confirm this bug.
It must be Mozilla:s fault because it works on reload.
Here's another site with the same problem which looks ****
everytime unless you press "reload".
http://www.d.kth.se/arskurs/d01/

Comment 9

[R.K.Aa.]

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

Comment 10

[David Tenser [:djst]]

I can confirm that this also happens on http://ps2.ign.com/ and I've even
managed to see the problem on http://www.mozillaquest.com (not that I ever visit
that site!)

This is *definitely* a bug in Mozilla, not site specific. It seems to be related
to tables.

Comment 11

[Kevin McCluskey (gone)]

-> Karnaze

Comment 12

[José Jeria]

Also seing this on Windows 2000 and Mac OS 9. Platform and OS should change to
All/All.

Today the actually have a page were they talk about Mozilla (for those who
speaks swedish...):
http://www.aftonbladet.se/vss/it/story/0,2789,172683,00.html

This works fine in Netscape 4. Add 4xp in keywords?

Comment 13

[Jonas Jørgensen]

all/all.

Comment 14

[André Dahlqvist]

Attachment: Screenshot of how it looks when it's *really* bad

It's not uncommon that it renderes this badly. This time it doesn't actually
help to reload the page, and it has been rendered this badly for at least two
days for me.

Comment 15

[Christopher Hoess (gone)]

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

Comment 16

[S-O Westberg]

I do not know which code that is used in different version's of the 
netscape/mozilla browsers.
I have this problem in mozilla 1.0 also (not as bad as in 1.1) .
Nescape 6.1 6.2 did similar error's on www.kuriren.nu (also a swedish paper)
Mozilla handles kuriren.nu correct.

Comment 17

[Håkan Waara]

Can someone please create a minimized testcase that shows the problem ?

Comment 18

[S-O Westberg]

I think this bug is fixed in Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1a+)
Gecko/2002062508 . Reloaded 2002061104 and the bug is there but it is not
present in the 2002062508 version. I also had a similar bug with the columns on 
http://java.sun.com/j2se/1.4/download.html that exists in the older vesion but not
in the newer. I would like to change the status to resolved on this bug.

Comment 19

[André Dahlqvist]

S-O Westberg, please see comment 5 in this bug. Lets leave this bug open for
quiet a while now, and let people truly verify that it does not appear, ever,
for say a month. This bug is *extremely* random, and I haven't seen it with a
bulid from the 1.0 branch for a few days now. But from comment 14 you can see
that I did see this with a build from the 1.0 branch just a few weeks ago.  I
will be very happy to resolve this worksforme myself if this continues for
everyone for a while, but based on this bugs history I'm not at all confident
it's fixed yet.

Comment 20

[André Dahlqvist]

Undoubtly, this looks very promising. I now tried a build from 2002-06-10 on
Linux, and the bug is visible. Re-did the test with a current built on the 1.0
branch and the bug is not there. I'm convinced that this bug is indeed fixed,
but rest assured I will re-open it if this ever comes back again:-)

Thanks to the unknown mozilla coder who fixed this! I will now, out of pure
curiosity, look in bonsai to see if I can see a recent checkin that might have
fixed this.

Comment 21

[José Jeria]

Bug visible using build 20020625 on Windows 2000. Arent this bug reports for the
trunk and not the branch?
Resolving this as WFM will not make this bug to be fixed on the trunk, which it
should be.

Suggesting changing status to REOPENED.

Comment 22

[André Dahlqvist]

I figured this would happen...

Comment 23

[David Tenser [:djst]]

To comment 20: Please let us know if you find any checkin that is related to
this. I find it surprising that such a strange bug just get fixed without anyone
knowing who did it :)

Comment 24

[S-O Westberg]

It is not all that odd bugs get fixed without that anyone know why. 
I think this bug is an "overwrite of a variable/constant" or an uninitilised
variable. This types of bugs comes and goes and are very hard to trackdown.
To test if this is the case I would change the linking order to see what happens
add some dummy variables and see if the error is changed.

Comment 25

[David Tenser [:djst]]

This bug is now worse than ever. Using build 2002072408 (Win 2000) and now the
pages looks totally weird. They are *extremely* long, you can scroll forever.
Still looks completely normal in IE.

Is this a regression of some sort?? 

Comment 26

[db]

This problem is still here in mozilla 1.1 (linux build 20020827).

Comment 27

[db]

Attachment: Testcase

Testcase extracted from aftonbladet.se

Comment 28

[db]

I've created a testcase that seems to show the problem every time.

On the other hand, this is an evil bug that have been here for ever so i'm not
surprised if it works for some of you :-)

For me the problem is only visible the first time when you load the page, so
close down mozilla and open the testcase. This is a bit strange since I
frequently see the bug at http://www.aftonbladet.se and I never close down
mozilla. On the webpage a reload does not always fix the problem while on the
testcase it seems like a reload always works.

I've tried it on mozilla 1.1 using linux, I hope this testcase works for you
other too (and most important for a mozilla developer). Please try.

Comment 29

[David Tenser [:djst]]

Very good testcase! I am able to reproduce it every time. Hopefully, we are now
able to fix this problem.

Comment 30

[karnaze (gone)]

About 95% sure this is a dup, please verify when bug 159363 is checked in.

*** This bug has been marked as a duplicate of 159363 ***

Comment 31

[André Dahlqvist]

I applied the patch in attachment 98341 [details] [diff] [review] in bug 159363 and the problem is
unfortunately still present at aftonbladet.se. REOPENING.

Comment 32

[Matthias Versen [:Matti]]

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

Comment 33

[Jerry]

assign it to me.

Comment 34

[Jerry]

I believe this is a dup of bug 156629.
also an image with align value inside table.

*** This bug has been marked as a duplicate of 156629 ***

Comment 35

[Torben]

I do not think it is a duplicate of bug 156629. There is one big difference:
The URL in bug 156629 is OK when loaded, reload makes it wrong, shift reload
makes it right again. In my testing this was 100% reproducible.
The URL in this bug has the opposite behaviour, wrong layout on first reload and
after shift-reload, fine with reload.
I think this bug should be reopened and kept open until a fix is checked in for
bug 156629, if this also fixes this bug then make it a duplicate.

Comment 36

[Jerry]

I compared the two bugs's testcase, they are very samilar.
they both have one image inside one table, that image has align attribute,  they
both give different layout when reloading and shift-reloading.
if remove align attri, they both works fine.
So I think they are dup.

as which layout is good or wrong, it depends the html designer.

Anyway, anyone who fix bug 156629 in the future should check its dup bugs to
make sure  
 they are dup.

Comment 37

[André Dahlqvist]

I'm going to reopen this and add a dependency on bug 156629. This bug has been
resolved before and a similar bug has always been filed on a later date, so I
would like to keep this open just to avoid any further duplicates. I will make
sure to dupe this one against 156629 if the checkin for that bug cures this one
as well.

Comment 38

[André Dahlqvist]

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

Comment 39

[Jerry]

Attachment: another testcase

more precise testcase, there are two table in it, one is ok, another is bad,
the only difference is that one set image's width 1px less than another.

Comment 40

[Jerry]

         block 0412A080 r=1 a=4452,UC c=4452,UC cnt=2191 
           text 04162890 r=2 a=UC,UC c=UC,UC cnt=2192 
           text 04162890 d=0,0 me=0 
           place 0409C5E8 r=2 a=UC,UC c=UC,UC cnt=2193 
           place 0409C5E8 d=0,0 me=0 
           img 0409C528 r=4 a=UC,UC c=3744,UC cnt=2194 
           img 0409C528 d=3744,361 me=3744 m=3744 
           text 0412A1EC r=2 a=UC,361 c=UC,UC cnt=2195 
           text 0412A1EC d=732,228 me=684 
           text 04162890 r=2 a=4452,UC c=UC,UC cnt=2196 
           text 04162890 d=0,0 
           place 0409C5E8 r=2 a=4452,UC c=UC,UC cnt=2197 
           place 0409C5E8 d=0,0 
           img 0409C528 r=2 a=4452,UC c=3744,UC cnt=2198 
           img 0409C528 d=3744,361 
           text 0412A1EC r=2 a=672,361 c=UC,UC cnt=2199 
           text 0412A1EC d=684,228 status=1
           text 0412A1EC r=2 a=672,UC c=UC,UC cnt=2200 
           text 0412A1EC d=684,228 me=684 
           text 0412A1EC r=2 a=4452,UC c=UC,UC cnt=2201 
           text 0412A1EC d=732,228 me=684 
          block 0412A080 d=4464,601 me=4464 m=684

during incremental reflow, block get d=4464 bigger than 4452,this is the problem.
   change component to block and inline

Comment 41

[Jerry]

add nsbeta1 keyword

Comment 42

[José Jeria]

This also happends with IE 6 SP1 sometimes. Maybe it is Aftonbladets HTML code
that sucks?

Comment 43

[David Tenser [:djst]]

It's both. There is a bug in Gecko though.

Comment 44

[David Tenser [:djst]]

Attachment: 100% reproducible testcase

I've found a page (which I've stripped down a bit) that has this bug every
time. 

Steps to reproduce:
1. Load the testcase. Notice how the page sucks.
2. Press Ctrl++ to zoom in, and then Ctrl+0 to restore zoom level
3. Repeat step 2 a few times and notice how the right "menu" on the page moves
around.

Comment 45

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Based on the testcases I believe this is a duplicate of bug 186593.  Could
anyone confirm that this bug no longer appears in builds on 2003-02-23 or later?
 If so, could you mark it a duplicate of bug 186593?

Comment 46

[David Tenser [:djst]]

I can no longer reproduce my 100% reproducible testcase in comment 44! That's a
very good sign.

Comment 47

[Torben]

Not fixed in 20030310-1.3, but seems to be fixed in 2003031108-trunk.

Comment 48

[David Tenser [:djst]]

Now my testcase renders even worse results. The length of the document now
differs greatly when following the steps to reproduce:

Steps to reproduce:
1. http://bugzilla.mozilla.org/attachment.cgi?id=114886&action=view
2. Press Ctrl++ to zoom in, and then Ctrl+0 to restore zoom level
3. Repeat step 2 a few times and notice how the right "menu" on the page moves
around AND how the length of the document changes.

Comment 49

[Tom Sommer]

I have the same problem on another page, I can solve it by doing a CTRL + + and
then CTRL + 0, but when I refresh the page again, the problem is back... and I
have to repeat the fix-procedure again....

I actually produced this bug on a page by just keep pressing F5 (was debugging)
and suddenly the bug was on that page, and now I can't get rid of it...

Using: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030320
Phoenix/0.5

Comment 50

[José Jeria]

Shouldn't this bug be marked fixed? The site renders fine now since bug bug
186593 was fixed. The issue mentioned in comment 48 - 49 is not really the same
issue.

Comment 51

[André Dahlqvist]

No, I've still seen this bug happen, although it didn't look as bad as before.
The normal "reload fixed it" applied.

Comment 52

[Tom Sommer]

I still have the problem, *nothing* is fixed here...

Although my problem is not the fontsize, it is based on the same problem, the
page loads like it's an end-less loop going on, hundreds of pages containging
generated because of some element being extended vertically... it is fixable,
like i mentioned in Comment 49, by using CTRL + + | CTRL  + 0, but still very
VERY annoying

Should I file this a a seperate bug, I know David Tenser has the same problem as
I do, and so he directed my attention to this bug.

This is defenetly something that could make me drop Phoenix, or maybe just stay
with an older build, since the new ones contain this bug that makes some sites
un-viewable.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030321 Phoenix/0.5

Comment 53

[Tom Sommer]

I can confirm Comment 48, since it is bassically my problem, the page becomes
huge in height... should this be transfered to another bug report? Or is it
already reported? This is a huge bug in Gecko

Comment 54

[Nilson Cain]

Also visible on http://home.earthlink.net/~nilsoncain sometimes. I use no tables
in this site; all layout is done using valid css and XHTML 1.0 Strict, so not a
coding problem on my site. I am using March 19th Phoenix build.

Comment 55

[Torben]

aftonbladet.se locks fine to me since bug 186593 was fixed. Since this is not a
meta bug for reload-related layout bugs, I am marking this as a dupe. Problems
with other pages than aftonbladet.se should be filed as separate bugs, but
search bugzilla throughly first, several such bugs already exist.

Please only reopen if this problem reapears on aftonbladet.se.

*** This bug has been marked as a duplicate of 186593 ***

Comment 56

[André Dahlqvist]

My comment 51 was seen on Aftonbladet.

Comment 57

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

If you see the problem, please attach a screenshot of what the problem is in
current builds.

Comment 58

[Tom Sommer]

Since the image is to large to be attached, I will post the URL

http://pub.tsn.dk/bugs/phoenix_146851_01.jpg

Please note the HUGE scroll bar. What you see in the bottom (the simple
yellow-black-white background) goes on-and-on for hundreds of pages, until
finally it displays the bottom of the site, all other HTML is rendered normally

Produced as described in Comment 48

Comment 59

[José Jeria]

I dont know if its me being blind, but that screenshot has nothing to do with 
this bug. This bug is about the text overlapping other text in the middle 
section. Since bug 186593 was checked in I have not seen this issue again. 
But now this bug seems to have become a meta bug for various bugs (scrollbar 
issue, maximizing text etc).

Comment 60

[André Dahlqvist]

José is right, please try to keep this bug about the original layout problem. I
have on one occasion seen a mild form of this layout bug happen again on a build
which had the fix checked in, which is why I would like to keep this bug open
for a a little while longer. Bugs about the layout issues on aftonbladet have
been resolved as worksforme so many times before because the bug has temporarily
vanished, just to come back later.

Comment 61

[David Tenser [:djst]]

Strike my comments in comment 48 about the page getting very long. That was in
fact a problem with the graphics drivers, and reinstalling Windows solved that.

Also, "100% reproducible testcase" only generates the original error in Mozilla
1.3 final, not in the latest nightly. So maybe this bug is fixed after all?

Comment 62

[Tom Sommer]

Re: Comment 61
Indeed, a new set of NVIDIA drivers fixed my problem as well...

Sorry for all the problems regarding this bug, it should however be known to
others who get this type of bug that a newer version of your Graphics Drivers
could solve the problem

Comment 63

[Daniel Wang]

David:
> Strike my comments in comment 48 about the page getting
> very long. That was in fact a problem with the graphics
> drivers, and reinstalling Windows solved that.

happen to know what bug # that might be? (see bug 194254)

Comment 64

[André Dahlqvist]

Attachment: Screenshot showing very bad first-time rendering on new build

[Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030327 Phoenix/0.5]

As far as I know, the build above should have the fix that people hoped would
fix this bug. Unfortunately, today I ran into the poor layout that can be seen
on the attached screenshot. After a reload the layout was good.

Comment 65

[Daniel Wang]

Attachment: Testcase 2 (.fig -> .gif)

I notice that in the test case (attachment 114886 [details]), there are 200+
images with wrong filenames (.fig instead of .gif). I've corrected
them all in this attachment. Reporter (André Dahlqvist) and everyone
else who has trouble w/ the site, can you try both this attachment and
attachment 114886 [details] and see if there is any difference.

Comment 66

[S-O Westberg]

This bug still exists in 1.3 . I think it is more common in 1.3 then in 1.2.1
and today it does not go away with reload.
http://www.aftonbladet.se/vss/nyheter/story/0,2789,291047,00.html

Comment 67

[Torben]

Re comment 66: The fix for bug 186593 is _not_ in 1.3, please test with 1.4a or
a current nightly.

Comment 68

[Samir Gehani]

adt: nsbeta1-

Comment 69

[André Dahlqvist]

Happened today with 2003-04-25 of Mozilla Firebird.

Comment 70

[Torben]

André, am I correct in assuming that you only see this with Phoenix/Firebird and
not "vanilla" Mozilla?

Comment 71

[Dan]

This seems to be fixed in 1.4beta (I saw this a lot in 1.3).

Comment 72

[André Dahlqvist]

I'm still seeing it occasionally with 2003-05-05 Mozilla Firebird.

Torben, since I am basically only running Mozilla Firebird these days, that's
what I notice it with. It's possible that this only happens on Mozilla Firebird
(maybe because it has a different delay time until rendering starts?), but I am
not sure about that.

Comment 73

[André Dahlqvist]

Happened again with plain Mozilla 2003-06-06, from the 1.4-branch.

Comment 74

[Daniel Wang]

can anyone who experience this problem produce a reduced testcase (see
http://www.mozilla.org/newlayout/bugathon.html#testcase) ?

Comment 75

[Magnus Melin [:mkmelin]]

Attachment: background image for the page (needed to see the overlap)

background image for a testcase

Comment 76

[Magnus Melin [:mkmelin]]

Attachment: flash banner that needed to reproduce

A flash banner needed for a testcase.

Comment 77

[Magnus Melin [:mkmelin]]

Attachment: html file for the testcase

This is a very reduced testcase which should be 100% reproducable. The problem
occurrs at least with Mozilla 1.4 and a recent nightly of Firebird (tested on
windows2000). 
The problem seems to be related to the width and hight of the flash banner. The
scripts below is what I found was causing the problem.

<script language="JavaScript">
document.write('<OBJECT classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
ID=banner WIDTH="250" HEIGHT="120">');
document.write('<PARAM NAME="movie"
VALUE="http://bugzilla.mozilla.org/attachment.cgi?id=130246&action=view">');
// remove the width and height in the next line and the bug dissappears
document.write('<EMBED
SRC="http://bugzilla.mozilla.org/attachment.cgi?id=130246&action=view"
WIDTH="468" HEIGHT="60" ></EMBED>');
document.write('</OBJECT>');
</script>

This was the first time a had this problem with 1.4, in 1.3 it was _very_
common. The bug wasn't visible anymore after a reload, but having it saved on
local disk it seems to be present all the time. I think the bug didn't show up
on reload since then it was anther set of banners there.

Comment 78

[André Dahlqvist]

Tried the testcase, and it does look similar to how this bug usually presents
itself. However, I tried the same with Opera 7.11 on Linux, and it also rendered
the page with an overflow.

Comment 79

[Magnus Melin [:mkmelin]]

The overlap is present in opera 7.11 on windows also, both opera and mozilla
uses the <embed> but IE just looks at the <object> -parameters. Moz supports
both
(http://www.mozilla.org/newlayout/testcases/printing/misc/embed_obj_tag.html)
but not the same way is IE. So basically it comes down to en error in
aftonbladet's coding?  

Comment 80

[Daniel Wang]

> So basically it comes down to en error in aftonbladet's coding?

seems so to me. Magnus Melin, thanks for the testcase
-> TE

Comment 81

[Pascal Chevrel:pascalc]

-> Swedish not Spanish

Comment 82

[José Jeria]

Havent seen this bug in ages. Visit Aftonbladet every day. Changing from
[e-mail]...

Comment 83

[Markus Långström]

I see it almost every time I visit Aftonbladet and have done so for a couple of
weeks (and builds).

Comment 84

[André Dahlqvist]

Yeah, it has entered one of those "bad periods" again where it happens almost
all the time. Can anyone who has a good understanding of the bug contact
Aftonbladet at [e-mail] and try to work with them to reach a
solution? I currently do not have the time to do it, nor do I know the exact
code bug.

Comment 85

[David Tenser [:djst]]

From Catarina Smedshammar at aftonbladet.se, at 2003-11-28 14:09:

> Hej David
> Vi ger upp den gamla risiga html-koden, och släpper en helt ny (och 
> förhoppningsvis felfri) sida i nästa vecka. Då ska vår sida se ok ut även
> i Mozilla - hoppas du har tålamod till dess!

This means that they'll probably change the html code soon which should solve
the problem. However, that doesn't mean the alignment bug in Gecko is
automatically fixed, but aftonbladet.se will render properly.

Comment 86

[José Jeria]

Maybe the alignment bug is not fixed, but its great news that they are 
redesigning, cause usually when you recommend Mozilla to anyone (in sweden) 
they complain about aftonbladet...

Comment 87

[David Tenser [:djst]]

The redesign of aftonbladet.se is complete. The site now renders without problems.

I'm not sure what to do with this bug though, since it's about a gecko bug that
still exists.

Comment 88

[db]

It might be complete, but it still have prolems.

Yesterday the blocks of the page was layed out badly, it looked like blocks that
should have been next to each other was under each other. When I reloaded the
page it looked fine again. This happend twice yesterday. So the text is not
overlapping as before, but it's still broken.

Reloading a page should not render it differently, no matter what.

Comment 89

[Kai de Leeuw]

They had problem with their ISP yesterday. It was also stated on their web site
for a while. So it was probably that.

Comment 90

[André Dahlqvist]

Unfortunately, I see the text overlapping problem mentioned in comment 88 too.

First the frontpage renders fine, but a reload (or shift-reload) later there is
text on top of one of the images. I saved the HTML of the badly layed out
version and the correctly layed out version, and the only difference between
them (apart from a comment from their publishing system, which puts in the
current date) is this:

Correct rendering
-----------------
<map name="mellanplus4">
<area shape="rect" coords="2,2,118,43" href="http://plus.aftonbladet.se/matvin/">
<area shape="rect" coords="123,2,243,43" href="http://plus.aftonbladet.se/tvtabla/">
<area shape="rect" coords="248,2,373,43" href="http://plus.aftonbladet.se/dujag/">

Bad rendering
-------------
<img src="http://www.aftonbladet.se/annons/plus/plus/mitten375_2.gif"
width="375" height="45" border="0" usemap="#mellanplus2">
<map name="mellanplus2">
<area shape="rect" coords="2,2,118,43" href="http://plus.aftonbladet.se/plusmail/">
<area shape="rect" coords="123,2,243,43"
href="http://plus.aftonbladet.se/webbspel/">
<area shape="rect" coords="248,2,373,43"
href="http://plus.aftonbladet.se/spotlight/">

So, the cause for bad rendering once again seams to be an ad.

Comment 91

[José Jeria]

How about adding a testcase?

Comment 92

[Magnus Melin [:mkmelin]]

Attachment: pic needed to reproduce

Comment 93

[Magnus Melin [:mkmelin]]

Attachment: testcase that shows text on an image

Comment 94

[José Jeria]

I can reproduce last added testcase, reloading fixes the problem. I guess this
shouldnt be tech envagelism then?

Comment 95

[Magnus Melin [:mkmelin]]

The original issue for this bug seems to be gone since aftnobladet started using
thier new code... Although it might have been an evangelism bug at some point, I
agree its not anymore. Also, most (all?) old attachemnts seem obsolete.

The testcase I created (comment #93) shows the text overlapping an image at
first, but after reload it displays correctly. Sometimes it does not even need a
reload, changing getween tabs may also help... So clearly it's something with
moz. Clear your cache to make sure you can reproduce, then it works always for
me atleast. 

Comment 96

[José Jeria]

Yes, this has somehow becomed a "all bugs on aftonbladet" bug. The original
problem that occured with the old design is gone (fixed?). 

I suggest closing this one and opening a new one. This is already very confusing.

Comment 97

[André Dahlqvist]

I'm resolving this bug as fixed, since their redesign fixed the original issue.
Someone please file the remaining problems (which I see too) in a new bug.

Comment 98

[Magnus Melin [:mkmelin]]

Remaining problem filed in bug 231498.