Last Comment Bug 289480 - (acid2) Tracking bug for acid2 (acid 2) test
(acid2)
: Tracking bug for acid2 (acid 2) test
Status: NEW
[reflow-refactor]
: meta
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: P2 normal with 262 votes (vote)
: ---
Assigned To: chris hofmann
: chris hofmann
Mentors:
http://acid2.acidtests.org/#top
: 291592 291710 292335 292513 294818 296641 303233 320703 341228 377928 (view as bug list)
Depends on: 398763 965966 1156 96976 191830 290290 290297 291060 291126 292295 296648 reflow-refactor 328241 b-order 359002 361523 363246 365191 365680 365809 389561 400813 409293 409329 409717 409825 415446 426616 663643
Blocks: 578114 579548
  Show dependency treegraph
 
Reported: 2005-04-07 15:36 PDT by Doug Wright
Modified: 2016-06-28 10:36 PDT (History)
215 users (show)
pavlov: blocking1.9-
reed: wanted1.9+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase for margin collapsing / clear bug (13.84 KB, text/html; charset=UTF-8)
2005-04-23 12:56 PDT, David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
no flags Details
Reduced version with space (1.31 KB, text/html)
2005-04-28 12:27 PDT, Taral
no flags Details
Screenshot (of attachment 181654.) (4.39 KB, image/png)
2005-05-25 06:13 PDT, Daniel Cater
no flags Details
Full Acid2 Testcase (13.96 KB, text/html)
2005-05-27 02:11 PDT, Matt
no flags Details
Current rendering of Acid2 (and the attached testcase) (2.44 KB, image/png)
2005-05-31 16:10 PDT, David Naylor
no flags Details
Current renderring (57.46 KB, image/png)
2005-10-02 09:33 PDT, Matt
no flags Details
Current Rendering (Trunk 02-10-2005 or 2005/10/02) (105.34 KB, image/png)
2005-10-02 10:24 PDT, RSpliet
no flags Details
rendering in firefox trunk build 2005-12-15 (3.80 KB, image/png)
2005-12-15 10:55 PST, Kadir Topal [:atopal]
no flags Details
Current render (20060127) (3.82 KB, image/png)
2006-01-27 08:01 PST, Michael K.
no flags Details
IE7 beta 2 preview rendering (10.19 KB, image/png)
2006-02-01 11:15 PST, Ian Macfarlane
no flags Details
Current rendering in trunk build 2006-02-28 (8.80 KB, image/jpeg)
2006-02-28 06:06 PST, Gábor Stefanik
no flags Details
acid2 screenshot after resize (37.16 KB, image/png)
2006-12-08 15:57 PST, Matp75
no flags Details
possible regression (18.59 KB, image/png)
2007-01-02 09:42 PST, Zibi Braniecki [:gandalf][:zibi]
no flags Details
Reftest (16.69 KB, patch)
2007-12-20 14:26 PST, Jeff Walden [:Waldo] (remove +bmo to email)
no flags Details | Diff | Splinter Review
Reference smiley for reftest (5.94 KB, image/png)
2007-12-20 14:30 PST, Jeff Walden [:Waldo] (remove +bmo to email)
no flags Details
acid2 test result The stange double height line (36.93 KB, image/png)
2008-03-06 00:22 PST, boiert
no flags Details
acid2 test result The zooming bug (33.88 KB, image/png)
2008-03-06 00:23 PST, boiert
no flags Details
acid2 test result The zooming bug persists (37.19 KB, image/png)
2008-03-06 00:24 PST, boiert
no flags Details
acid2 test result The zooming bug animation (184.97 KB, image/gif)
2008-03-06 01:42 PST, boiert
no flags Details
Broken acid2 on minefield nightly (2009-04-07) (4.76 KB, image/png)
2009-04-08 07:57 PDT, Bruno Lustosa
no flags Details

Description Doug Wright 2005-04-07 15:36:20 PDT
:-(

On the other hand, we're better than IE6 and Opera 8 :-)
Comment 1 Doug Wright 2005-04-07 15:39:36 PDT
Seriously, a lot of people will be interested in tracking/filing dupes on this,
so this bug is for that purpose - I fully expect any actual 'fixing' to be to
take place in other bugs.
Comment 2 Doug Wright 2005-04-08 02:31:03 PDT
dbaron - I'm wondering why you added 9458 to this, when the test doesn't use
inline-block?
Comment 3 David Betz 2005-04-11 17:56:40 PDT
Confirmed.  This is not good...

http://webstandards.org/act/acid2/test.html#top

Being the BEST still doesn't make us right.
Comment 4 Ben Basson 2005-04-11 18:04:12 PDT
ROBO Design has produced a summary of Firefox and Opera's CSS failings according
to the W3C's CSS2.1 Test Suite. It's another good testcase for this bug.
http://www.robodesign.ro/_gunoaie/opera_vs_firefox.htm
Comment 5 Jeff Walden [:Waldo] (remove +bmo to email) 2005-04-11 19:42:48 PDT
(In reply to comment #4)
> ROBO Design has produced a summary of Firefox and Opera's CSS failings
> according to the W3C's CSS2.1 Test Suite.

I'm hesitant to pay any real attention to this "test suite".  First, it's
described on the page as "beta" (scroll to bottom at link).  Second, when as far
as I can see a relatively simple test like their "URL" test
<http://snurl.com/css21_ts_url> is completely incorrect (there's only one rule
for each test paragraph, and each rule is rendered properly), I don't expect
much from the others.  (If you want to discuss this further or point out any
mistakes I made in this diagnosis, I'd be happy to do so via private email.)

Also, this is a tracker bug.  Personally, the only email I'd like to get for
this bug is for the adding and removing of dependencies and dependency bugfixes.
 I (and probably others) would prefer if people could reserve comments for more
appropriate forums (such as Mozillazine or possibly the newsgroups), as most
comments here aren't likely to be helpful.
Comment 6 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-04-12 20:58:55 PDT
We need volunteers to boil down the test into separate minimized testcases for
individual bugs, and to file those bugs in Bugzilla if they're not filed
already, and to attach them as dependencies of this bug.
Comment 7 Sebastian Brocks 2005-04-13 05:12:26 PDT
Dupe of 286556.
Comment 8 José Jeria 2005-04-13 05:51:46 PDT
(In reply to comment #7)
> Dupe of 286556.

No, totally different url
Comment 9 Thomas K. (:tom) 2005-04-13 15:12:41 PDT
Don't worry, Amaya hates Acid2 too, but in _much worse ways_.
http://img29.echo.cx/img29/5643/amayahatesacid23ge.png

Safari is getting some bugfixes, from Hyatts blog:
http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007938
Comment 10 Nikolas 'Atrus' Coukouma 2005-04-13 23:21:04 PDT
Adding info from #286556
Comment 11 Nikolas 'Atrus' Coukouma 2005-04-14 00:18:27 PDT
Made the same mistake as in comments 7/8, d'oh.
Comment 12 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2005-04-14 01:45:22 PDT
I've just gone through the test, making changes to the test page to work around
known Mozilla bugs, to try and figure out what problems it's showing.  I've done
all but Row 14 so far.

 * both row 2 and rows 10/11 show a variant of bug 69745 that should perhaps be
filed as a separate bug.  (It's a variant because it's a right float inside of
an absolutely positioned container rather than a right float inside of a left
float.)

 * rows 4 and 5 show bug 1156 on the outermost object (the bit about not
handling fallback correctly when we shouldn't display the object)

 * rows 4 and 5 show bug 96976 on the middle object

 * rows 4 and 5 show bug 1156 on the outermost object (the bit about not
displaying the object when we should display the object)

 * rows 4 and 5 show at least one z-ordering bug (I can work around the whole
z-ordering business by adding #eyes-a { position: relative; z-index: 2; }).  I
think bug 290290 is part of the problem, but I'm not even sure of that (I wasn't
paying close enough attention to the result differences).
Comment 13 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2005-04-14 01:48:16 PDT
(In reply to comment #12)
>  * rows 4 and 5 show bug 1156 on the outermost object (the bit about not
> displaying the object when we should display the object)

That (the second reference to bug 1156) should have referred to the *innermost*
object.
Comment 14 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2005-04-14 02:41:39 PDT
The following is an excerpt from email I sent about row 14 (although
it's worth noting that with the introduction of baseline rules for
inline-block and inline-table in section 10.8.1, the definitions of
baselines in CSS2.1 are rapidly moving towards being completely
different in different contexts):

I'm concerned partly because the guide [2] completely omits what makes
Row 14 really hard:  baseline alignment between table cells.  (Mozilla
gets the anonymous table object construction correct:  I checked the
internal representation.)  See the tests two and three below the purple
box in [3] for examples of baseline alignment in table cells.

I'm pretty sure the test in Row 14 is testing behavior that's undefined
in the CSS2.1 specification.  Perhaps it should be defined, but I also
wonder if the test should be easier, given that it's not defined and
nobody's noticed yet, and also given that the current test seems to
penalize implementations that make more of an effort to implement
baseline alignment in tables.


So, let's look at what's going on.  We have a table with four cells.

The first cell is an element in the source tree that has a height of
1em.  Since CSS 2.1 says [1]:
  # if it has none, the bottom of the cell box
the baseline of the first cell is at the bottom of its 1em height.

The third cell is just like the first cell, except its explicit height
is 0.5em, so its baseline is at the bottom of that 0.5em height.

The fourth cell is a little more interesting.  It's an anonymous cell
containing a block with an explicit height of 1em.  So now we enter the
rule:
  # the baseline is the baseline of whatever object is displayed in the
  # cell
The baseline of a block with no line boxes is currently undefined in the
specification.  However, preference for avoiding discontinuities (as a
block with explicit height moves from two lines to one line to zero
lines) suggests to me that it should be the top of the block (and this
is what Mozilla implements).  This alone would be enough to make the
Acid2 test incorrect, since it's an alignment point within the 1em of
height different from the first cell's.

You might think I'm done now.  But I skipped the second cell so that I
could come back to it.  The second cell is an anonymous table cell
wrapping an explicit table with height 1em, which itself contains an
anonymous cell.  So we're again dealing with the rule I quoted in the
previous paragraph, except now we're wondering what the baseline of a
*table* is.  This is *also* undefined in the specification.  Mozilla
happens to treat it as the bottom of the table.  However, it would also
make sense (and probably even be better) to define it as the baseline of
the first row of the table.  But this is *also* undefined in CSS2.1 in
this case, because the row in question gets its height from an explicit
height.  However, if we want the spec to be compatible with the real
world it must be defined so that the extra space within the row is added
as extra space below each cell, which puts the baseline of the table at
the top of the table.

Given that the alignment points above end up at both the top and the
bottom of the 1em height, I think Mozilla's behavior of expanding the
table to 2em height is at least acceptable if not the only correct
behavior.  That said, I'd be highly surprised if Mozilla didn't have a
bunch of bugs in baseline alignment of table rows.
Comment 15 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2005-04-14 03:23:39 PDT
The z-ordering issue is that view creation is incompatible with paint layers,
and background-attachment:fixed causing view creation breaks z-ordering.  roc,
do we have a bug on that somewhere?  I sure remember discussing it before, and
it's a known architectural problem.

Hixie and I are arguing about the baseline alignment business.
Comment 16 Mikko Rantalainen 2005-04-14 04:08:48 PDT
In addition, acid2 test page breaks down further if the viewport is made
narrower. Pressing reload "fixes" the rendering (other bugs are still visible).
Comment 17 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2005-04-14 15:24:33 PDT
The z-ordering bug in rows 4 and 5 is bug 191830 (thanks to roc for finding
that), although actually once that's fixed, we'd need to ensure that bug 290290
is fixed as well (although bug 290290 may actually be symptomless in many cases).
Comment 18 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2005-04-14 15:28:05 PDT
(In reply to comment #16)
> In addition, acid2 test page breaks down further if the viewport is made
> narrower. Pressing reload "fixes" the rendering (other bugs are still visible).

The test relies on scrolling to a named anchor to test fixed positioning (and
fixed background-attachment).  We should perhaps have a bug on tracking the
named anchor if the user hasn't yet scrolled since navigating to that anchor (it
would depend on a bunch of other named anchor bugs).
Comment 20 Sjoerd Visscher 2005-04-17 02:46:33 PDT
Please share. Those are members only posts.
Comment 22 Snap 2005-04-20 06:37:19 PDT
The wasp made a guide explaining the acid2 test:
http://www.webstandards.org/act/acid2/guide.html
Comment 23 Malcolm Rowe 2005-04-21 01:23:40 PDT
Note that hyatt documents what appears to be a bug in the test, here:
http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#007977

"Basically the test has the smile clearing a float with a bottom margin of
negative 1em. This means that the bottom outer edge of the float is actually 1em
up from the bottom of the rendered float content. Thus the smile is supposed to
overlap the float by 1em. This is clearly not the intent of the test.

The test put a 1em margin on a block inside the smile assuming that this margin
would not collapse into the float clearance. However the spec is quite clear
that this collapsing is required, especially given that this block's margin was
used in the theoretical collapse computation that led to the understanding that
the clear was necessary in the first place."
Comment 24 Uri Bernstein (Google) 2005-04-23 08:06:24 PDT
*** Bug 291592 has been marked as a duplicate of this bug. ***
Comment 25 Daniel Cater 2005-04-23 09:44:16 PDT
Acid2 Browser Test is now at version 1.1 after a few bugs in the test itself
have been fixed.

Updated Test - http://webstandards.org./act/acid2/test.html#top
Updated Guide - http://webstandards.org./act/acid2/guide.html
Reference Rendering (apparently un-updated) -
http://webstandards.org./act/acid2/reference.html

Firefox seems to render this slightly worse than before now.
Comment 26 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2005-04-23 12:56:09 PDT
Created attachment 181654 [details]
testcase for margin collapsing / clear bug

Anybody want to simplify this and figure out which bug it is (or file a new
one, if needed)?
Comment 27 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-04-24 10:00:09 PDT
*** Bug 291710 has been marked as a duplicate of this bug. ***
Comment 28 Hixie (not reading bugmail) 2005-04-25 07:18:27 PDT
See bug 291060 for details on how the baseline issue was resolved.
Comment 29 Taral 2005-04-28 12:27:12 PDT
Created attachment 182089 [details]
Reduced version with space

It looks like there's a collapsing margins bug. According to the guide, the div
child of .smile's margin-top should be collapsing, but it's not. We're seeing
it. That's what's causing the gap.
Comment 30 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-04-28 14:53:26 PDT
Taral, can you simplify that a bit more and file a bug against me?
Comment 31 Michael Ward 2005-04-28 21:24:58 PDT
I think I got it as simple as possible, however, I don't have any way to assure
myself that my testcase is still showing the bug or I removed too much...filed
bug 292295 with the testcase
Comment 32 Elmar Ludwig 2005-04-29 05:35:10 PDT
*** Bug 292335 has been marked as a duplicate of this bug. ***
Comment 33 Jo Hermans 2005-05-01 06:25:07 PDT
*** Bug 292513 has been marked as a duplicate of this bug. ***
Comment 34 Daniel Roberts 2005-05-13 10:07:43 PDT
Now that Safari passes the Acid2 test, I should think this seriously raises the
bar for other browsers.  If Mozilla doesn't pass this test in the next major
release, I should think it will get some bad press and not be well received in
the web development community.
Comment 35 Nicholas Shanks 2005-05-13 15:12:08 PDT
Well I think the web development community couldn't really care less about acid 2 - it tests things that 
we/they don't use very much at all. It's clueless people like C|Net overhyping it that you have to be worried 
about! It would be much better to fix bugs like the lack of DTD parsing (which completely breaks XML) 
than obscure comment parsing bugs.
Comment 36 Dwight Brown 2005-05-13 16:23:30 PDT
I disagree. Comment parsing errors aside I consider it very valuable.  As a
developer I want to know that every browser is rendering identical.  The Acid2
test is a good cumulative test to easily verify crazy amounts of CSS rendering
identical across browsers.

There are plenty of things that are in the test that are valuable.  And if you
are going to be standards compliant, then be that way with comments as well, heh.
Comment 37 Alex Vincent [:WeirdAl] 2005-05-13 17:49:10 PDT
This is all well and good for people to comment how important it is to pass Acid
2, but it doesn't speed up the process of actually landing fixes (which may not
exist yet).

If you want to block a release for it, set one of the blocking flags to ?. 
Expect that it will be quickly minused, unless one of the drivers is feeling
charitable.  I understand drivers are trying to get Moz App Suite 1.8b2 out the
door, and it's a pretty safe bet it will not pass Acid 2 "this late in the game".

Don't take my word for what drivers will do (I'm not one of them, nor even
close), but please don't spam this bug with comments that everyone on the cc
list receives that don't actually help us get Acid 2 bugs fixed...
Comment 38 Vedran Miletic 2005-05-14 02:13:37 PDT
I don't think this is going to be fixed before 1.9a. It's because Acid2 isn't a
highly critical issue, and fixing it could break lots of other things, and
developers surely don't want that to happen.
Comment 39 Dmbtech 2005-05-14 10:28:05 PDT
My concern is that if for some strange wacko reason, IE is able to render it
correctly in its next version (which i doubt they will do, but they might for
publicity), the press and people will be all over us and everything saying that
IE is more standards complient than mozilla (which is not true, but thats how
the press works). If that happens, were in big trouble.
Comment 40 Scott Baker 2005-05-14 10:41:29 PDT
This is *not* the place to debate the merits of whether or not firefox should or
shouldn't pass the ACID2 test. It's simply a collection of bugs that are
preventing it from passing. If you want to debate the issue please take it a
message board or mailing list and stop with the bug-spam.
Comment 41 Jaime Mitchell (use bugmail@jaimem.org.uk for email) 2005-05-19 11:00:50 PDT
*** Bug 294818 has been marked as a duplicate of this bug. ***
Comment 42 u88484 2005-05-25 05:47:55 PDT
just wanted to add that something regressed. The picture is now rendered worse.
Comment 43 Daniel Cater 2005-05-25 06:06:31 PDT
Yes, the "smile" is now over to the right more, leaveing a large black area.

This can be seen in attachment 181654 [details] (simplified over the real test at least.)
When this bug was filed, that attachment would render fine. When the attachment
was attached (comment 26,) there was a small problem that there was an thin
white line between the nose and the smile. Now, a new problem can be seen (I
haven't been checking acid2 regularly, so all I know is that it regressed
between 23rd April and 23rd May...)
Comment 44 Daniel Cater 2005-05-25 06:13:12 PDT
Created attachment 184496 [details]
Screenshot (of attachment 181654 [details].)


Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050523
Firefox/1.0+

Screenshot showing the current rendering of attachment 181654 [details].
Comment 45 Jason Daly 2005-05-25 13:20:15 PDT
The actually acid2 test (http://www.webstandards.org/act/acid2/test.html)
(diferent than the attached testcase) renders a lot worse than the testcase, and
it has gotten worse, sometime in the past week.
Comment 46 Matt 2005-05-27 02:11:02 PDT
Created attachment 184663 [details]
Full Acid2 Testcase

Adding the full Acid2 test in response to Comment #45
Comment 47 David Naylor 2005-05-31 16:10:27 PDT
Created attachment 184965 [details]
Current rendering of Acid2 (and the attached testcase)

Added a new screenshot of the current Acid2 rendering, since the previous
screenshot was too good to be true.
Comment 48 Aaron Slunt 2005-06-02 15:56:37 PDT
(In reply to comment #47)
> Created an attachment (id=184965) [edit]
> Current rendering of Acid2 (attached testcase)
> 
> Added a new screenshot of the current Acid2 rendering, since the previous
> screenshot was too good to be true.

The screenshot you refer to as being too good to be true is exactly what I see.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050531
Firefox/1.0+
Comment 49 David Naylor 2005-06-02 22:43:35 PDT
Not for the actual, full acid2 test. What you are looking at is a reduced testcase.

http://www.webstandards.org/act/acid2/test.html
Comment 50 José Jeria 2005-06-04 12:07:20 PDT
*** Bug 296641 has been marked as a duplicate of this bug. ***
Comment 51 Taral 2005-06-04 15:11:57 PDT
Finally tracked down the bug with that small gap. Opened bug 296648, but can't
assign to Robert.
Comment 52 Cedric Roijakkers 2005-06-06 06:36:24 PDT
FYI: Konqueror now passes the Acid2 test. They incorporated some patches from
Safari (by David Hyatt, more at
http://weblogs.mozillazine.org/hyatt/archives/2005_04.html#008042 ), and wrote
the additional stuff themselves.

Info here: http://www.kdedevelopers.org/node/view/1129
Comment 53 Gérard Talbot 2005-06-06 19:51:07 PDT
Just for your info.

Apparently, ICab 3.0 passes the acid2 test.

http://santek.no-ip.org/~st/tests/iCab/screenshots/iCabAcid2.png

and Opera 8.01 has made considerable progress into its rendering of acid2 testpage.
Comment 54 Ryan VanderMeulen [:RyanVM] 2005-06-06 19:56:15 PDT
(In reply to comment #53)
> Just for your info.
> 
> Apparently, ICab 3.0 passes the acid2 test.
> 
> http://santek.no-ip.org/~st/tests/iCab/screenshots/iCabAcid2.png
> 
> and Opera 8.01 has made considerable progress into its rendering of acid2
testpage.

It's been said many times already in this bug, but I'll say it again. This is
NOT a bug to spam every time another browser makes headway on the test or every
time you have a comment about Firefox not passing it. Take that talk to the
Mozillazine forums.
Comment 55 Ger Teunis 2005-06-06 23:27:06 PDT
(In reply to comment #54)
> This is
> NOT a bug to spam every time another browser makes headway on the test or every
> time you have a comment about Firefox not passing it. Take that talk to the
> Mozillazine forums.

For discussion go to this forum thread:
http://forums.mozillazine.org/viewtopic.php?t=247588&highlight=acid2

I agree, but don't be to **** the commenters, this is a top-25 bug and the
community just wants to make sure this bug gets priority because they feel it
doesn't right now. Commenting/voting in bugs is our only way of getting
attention from the real drivers.
Comment 56 timeless 2005-06-07 00:04:50 PDT
bugzilla is for developers. if you want to get attention for bugs, post patches.
otherwise please drop the noise to zero so we can get back to work.
Comment 57 Christian :Biesinger (don't email me, ping me on IRC) 2005-06-07 05:21:31 PDT
> Commenting/voting in bugs is our only way of getting
> attention from the real drivers.

it's an excellent way to annoy such people.
Comment 58 Hixie (not reading bugmail) 2005-06-07 05:30:39 PDT
> Commenting in bugs is our only way of getting attention from the real drivers.

Actually the only way to get their attention in a way likely to get the bug
fixed is to send them money or to attach patches. Everything else merely has a
negative effect. (And money doesn't even work with all the drivers.)
Comment 59 Ger Teunis 2005-06-07 06:09:19 PDT
I'm not saying we should annoy anyone with offtopic comments! Sorry if I gave
that impression. Please only post usefull comments. Many _usefull_ comments and
many votes means it is an important bug and may help, that was my point. (sorry
for this chain of offtopic comments, my bad)
Comment 60 Doug Wright 2005-07-18 14:48:08 PDT
Bug 244135 shows up on the test tour page. Not strictly part of the test, but...
Comment 61 Cedric Roijakkers 2005-07-28 13:41:31 PDT
[Offtopic] No fears yet, Beta1 of IE 7.0 does not pass the Acid2 test by far!

Check screenshot at my site: http://images.ajunne.be/IE7/acid2.png
Comment 62 Matt Cosentino 2005-07-29 09:53:24 PDT
> [Offtopic] No fears yet, Beta1 of IE 7.0 does not pass the Acid2 test by far!

That's exactly what it looks like in IE 6.0, no surprise there.
Comment 63 PikeUK 2005-08-03 07:04:27 PDT
*** Bug 303233 has been marked as a duplicate of this bug. ***
Comment 64 RSpliet 2005-08-08 15:22:15 PDT
I've checked line 10 and 11, and the incorrect rendering of the smile is caused
by the "width: auto" in the ".smile div div" rule in the CSS. For some reason
the width: auto means a width of 0. That plus the 1em border means only the 2em
on the right will be painted yellow. By setting it fixed to 8em in the CSS the
smile (line 10 and 11) gets rendered correctly.
On http://www.w3.org/TR/CSS21/visudet.html#blockwidth it explains how the width:
auto should be calculated, meaning the Acid 2 test appears to be correct, and
the rendering wrong. Don't blaim me if I missed something out, I'm only 17 ;)
Comment 65 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2005-08-08 15:53:06 PDT
See comment 12, first bullet point.
Comment 66 Matt 2005-10-02 09:33:24 PDT
Created attachment 198228 [details]
Current renderring

Nobody's given an updated image, so here you go.
Comment 67 Matt 2005-10-02 09:37:29 PDT
Comment on attachment 198228 [details]
Current renderring

False alarm, it seems to have not changed much (or at all), even with bug 1156
fixed.
Comment 68 RSpliet 2005-10-02 10:24:31 PDT
Created attachment 198232 [details]
Current Rendering (Trunk 02-10-2005 or 2005/10/02)

What the current rendering truely is like in the trunk. By squashing that
latest bugs the eyes now render.
Comment 69 Francesco Montefoschi 2005-10-08 12:26:42 PDT
(In reply to comment #68)
> What the current rendering truely is like in the trunk. By squashing that
> latest bugs the eyes now render.

someone know when it will be fixed in the branch too?
Comment 70 Robin Whittleton 2005-10-08 12:39:12 PDT
I doubt it will be. It's get into a release branch the next time the trunk
branches (in preparation for Fx2.0 most likely).
Comment 71 Worcester12345 2005-10-19 21:50:30 PDT
Should this bug include "depends on" for Bug 312639 ?
Comment 72 Daniel Cater 2005-10-28 07:25:32 PDT
The bottom of the mouth is now fixe (by bug 291060 I think), but something regressed in the bottom row (there is a red rectangle out on the left, below the face).

   </ul>
   <div class="image-height-test"><table><tbody><tr><td><img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAABACAIAAAFSDNYfAAAAaklEQVR42u3XQQrAIAwAQeP%2F%2F6wf8CJBJTK9lnQ7FpHGaOurt1I34nfH9pMMZAZ8BwMGEvvh%2BBsJCAgICLwIOA8EBAQEBAQEBAQEBK79H5RfIQAAAAAAAAAAAAAAAAAAAAAAAAAAAID%2FABMSqAfj%2FsLmvAAAAABJRU5ErkJggg%3D%3D" alt=""></td></tr></tbody></table></div>
  </div>
 </body>

Is the source for that red image. The guide <http://www.webstandards.org/act/acid2/guide.html> has information on this, under the heading "After Row 14".
Comment 73 Stefan Vallaster 2005-11-01 07:45:52 PST
i get this javascript errors with 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

Errors:
Error: Expected ']' to terminate attribute selector but found 'two'.  Ruleset ignored due to bad selector.
Source File: http://www.webstandards.org/act/acid2/test.html#top
Line: 43

Error: Unknown property 'error'.  Declaration dropped.
Source File: http://www.webstandards.org/act/acid2/test.html#top
Line: 94

Error: Unknown property 'm
rgin'.  Declaration dropped.
Source File: http://www.webstandards.org/act/acid2/test.html#top
Line: 97

Error: Selector expected.  Ruleset ignored due to bad selector.
Source File: http://www.webstandards.org/act/acid2/test.html#top
Line: 98

Error: Error in parsing value for property 'width'.  Declaration dropped.
Source File: http://www.webstandards.org/act/acid2/test.html#top
Line: 99

Error: Expected 'important' but found 'error'.
Source File: http://www.webstandards.org/act/acid2/test.html#top
Line: 100

Error: Expected end of value for property but found 'pink'.  Error in parsing value for property 'background'.  Declaration dropped.
Source File: http://www.webstandards.org/act/acid2/test.html#top
Line: 101
Comment 74 Alfred Kayser 2005-11-01 10:27:31 PST
These are 'error's on purpose by the acid2 test.
See http://www.webstandards.org/act/acid2/guide.html
for an explanation of the code of acid2.
For example the 'm argin' thing refers to m\argin which parses according to the CSS 2.1 standard to m(U+000A)rgin (the \a is parsed as an hex number).
So, the parser is parsing them right.
Question is what should happen in some of these cases, like: 'background-color: red pink'? Should the whole statement be dropped or only the 'pink' part?
Comment 75 u88484 2005-11-01 10:37:08 PST
Just wanted to add:

"With today's release of Mac OS X 10.4.3, Apple's Safari RSS (version 2.0.2/416.12) is the first (publicly-released, non-beta, non-preview) browser to successfully pass the Acid2 test."

Source: http://www.webstandards.org/buzz/archive/2005_10.html#a000584
Comment 76 Matt 2005-11-01 15:14:04 PST
(In reply to comment #75)
> Just wanted to add:
> 
> "With today's release of Mac OS X 10.4.3, Apple's Safari RSS (version
> 2.0.2/416.12) is the first (publicly-released, non-beta, non-preview) browser
> to successfully pass the Acid2 test."
> 
> Source: http://www.webstandards.org/buzz/archive/2005_10.html#a000584
> 

Thanks for the very old information.  We already know that Webkit/KHTML have finally passed the test for at least a couple months.  Not to sound elitist (well, actually, yes), but the Gecko renderring engine is far more complex and overall superior to the KHTML engine, so it is prone to having more bugs, that of which including how to support invalid and/or broken markup and styling.
Comment 77 Christian :Biesinger (don't email me, ping me on IRC) 2005-11-01 15:31:04 PST
I don't think that gecko's acid2 issues have anything to do with invalid markup. certainly not those of them that I know.
Comment 78 Gábor Stefanik 2005-11-04 10:29:01 PST
(In reply to comment #74)
> These are 'error's on purpose by the acid2 test.
> See http://www.webstandards.org/act/acid2/guide.html
> for an explanation of the code of acid2.
> For example the 'm argin' thing refers to m\argin which parses according to the
> CSS 2.1 standard to m(U+000A)rgin (the \a is parsed as an hex number).
> So, the parser is parsing them right.
> Question is what should happen in some of these cases, like: 'background-color:
> red pink'? Should the whole statement be dropped or only the 'pink' part?
> 

The whole statement should be dropped, since it's invalid.
Comment 79 Matt 2005-11-15 16:25:50 PST
(In reply to comment #68)
> Created an attachment (id=198232) [edit]
> Current Rendering (Trunk 02-10-2005 or 2005/10/02)
> 
> What the current rendering truely is like in the trunk. By squashing that
> latest bugs the eyes now render.

Uh, no, that it doesn't.  Still looks the same as it did for me.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051115 Firefox/1.6a1 ID:2005111504
Comment 80 Worcester12345 2005-11-28 10:35:37 PST
In the 11/27 Mozilla Suite build, it puts in the green eyes after a reload/refresh, but not in Firefox. Both in branch.
Comment 81 Kadir Topal [:atopal] 2005-12-15 10:55:14 PST
Created attachment 205984 [details]
rendering in firefox trunk build 2005-12-15

FYI: Current rendering in firefox trunk builds after the latest checkin.
Comment 82 Ryan Flint [:rflint] (ping via IRC for reviews) 2005-12-17 23:50:10 PST
*** Bug 320703 has been marked as a duplicate of this bug. ***
Comment 83 Randy J. Anderson 2005-12-18 00:03:41 PST
Oops. I filed a bug report about this bug when you posted about this bug before I did! 

I already was accused of not searching when I did searched for "acid"! 

Im not perfect. :(
Comment 84 Matt 2005-12-18 11:20:01 PST
(In reply to comment #81)
> Created an attachment (id=205984) [edit]
> rendering in firefox trunk build 2005-12-15
> 
> FYI: Current rendering in firefox trunk builds after the latest checkin.
> 

It's only been three days since that renderring, and now it looks like absolute ****.  Need a screenshot, or can everyone else using the 20051218 build see this as well?
Comment 85 u88484 2005-12-18 13:32:32 PST
(In reply to comment #84)
> It's only been three days since that renderring, and now it looks like absolute
> shit.  Need a screenshot, or can everyone else using the 20051218 build see
> this as well?

Still looks like the 2005-12-15 build screenshot to me

Comment 86 Matt 2005-12-18 20:59:15 PST
Okay, I don't know why, but now my renderring is nearly the same as attachment 205984 [details].  I stil don't get any eyes, and the thing on the second line that's way off to the right is _completely_ off to the right for me.
Comment 87 Kadir Topal [:atopal] 2005-12-18 21:28:13 PST
Resize the window, I didn't want to upload more than necessary.
Comment 88 Michael K. 2006-01-27 08:01:40 PST
Created attachment 209845 [details]
Current render (20060127)

Shows the progress made after bug 317375 (frame display lists) landed.
Comment 89 Ian Macfarlane 2006-02-01 11:15:59 PST
Created attachment 210373 [details]
IE7 beta 2 preview rendering
Comment 90 War59312 2006-02-01 11:56:24 PST
(In reply to comment #89)
> Created an attachment (id=210373) [edit]
> IE7 beta 2 preview rendering

haha Dang that's sad. :(

And I thought IE 7.0 was suppose to be more web standards compliant. Guess not. ;)
Comment 91 Diego Calleja 2006-02-01 12:49:32 PST
Everybody knows that IE doesn't passes the acid2 test, but this is not the right place to discuss about it unless it help in some way to fix mozilla. Please delete the IE screenshot and take it and the discussion to forums.mozillazine.org, it's a much better place to discuss such things
Comment 92 Gábor Stefanik 2006-02-28 06:06:29 PST
Created attachment 213450 [details]
Current rendering in trunk build 2006-02-28

Broken again! Somebody have checked in something buggy (possibly from the reflow-refactoring branch), and now diagonal lines can be seen on the borders and in place of the "smile"! We are once again farther from passing the test!
Comment 93 Michael K. 2006-02-28 07:49:09 PST
Stefanik, see bug 328241. This is a cairo bug.
Comment 94 Noa Groveman 2006-03-10 13:20:27 PST
Looks like the latest Opera build passes the Acid2 test: http://weblog.timaltman.com/node/832

boo hoo!
Comment 95 Piotr Komoda 2006-03-10 18:44:22 PST
(In reply to comment #94)
> Looks like the latest Opera build passes the Acid2 test

Yup, it looks like this.... until you scroll :>
(checked on build 8265)
Comment 96 Patrick 2006-03-11 01:38:48 PST
(In reply to comment #95)
> Yup, it looks like this.... until you scroll :>
> (checked on build 8265)


"The test uses fixed positioned elements, so that's expected."
That is also the behavior Mozilla should display after this bug and its dependencies are fixed.
Comment 97 Thomas Winwood 2006-03-11 14:39:57 PST
I blogged on this at http://ketsuban.net/2006/03/firefox-hairs-breadth-from-acid2.html - I've also given the results of the few tests I've done as a result of reading the guide and the code from the Acid2 test. Hopefully this should help Firefox towards Acid2 perfection.
Comment 98 Damian Yerrick 2006-04-17 13:27:46 PDT
It appears that this has been fixed on the reflow branch:
http://diary.e-gandalf.net/2006/04/12/meet-mr-face/
Comment 99 gabe 2006-05-23 16:32:28 PDT
when will reflow branch get on trunk
Comment 100 Ryan VanderMeulen [:RyanVM] 2006-05-23 16:35:31 PDT
http://wiki.mozilla.org/Gecko_1.9_Alpha_Planning
Comment 101 Simon Bünzli 2006-06-12 05:11:16 PDT
*** Bug 341228 has been marked as a duplicate of this bug. ***
Comment 102 Gábor Stefanik 2006-07-03 09:50:28 PDT
Confirming that reflow branch builds pass Acid2. For anybody who want to test it for himself/herself, "around-weekly" builds are available at http://netrolller3d.uw.hu/fireflowfox.html.
Comment 103 Gábor Stefanik 2006-07-04 09:46:15 PDT
Link died, here is the new one: http://fireflow.zendurl.com
Comment 104 Gábor Stefanik 2006-07-04 10:52:27 PDT
Just noticed another issue, that is present even on the reflow branch: The nose is 1px off to the right and 1px up. A similar issue was also encountered and fixed by the Opera team (read more at http://weblog.timaltman.com/node/802 ). They have also created some testcases that might help fixing this bug.

http://timaltman.com/acid2/test014-1.html (passed)
http://timaltman.com/acid2/test014-2.html (failed)
http://timaltman.com/acid2/test014-3.html (failed)
http://timaltman.com/acid2/test014-4.html (passed)
http://timaltman.com/acid2/test014-5.html (failed)
http://timaltman.com/acid2/test014-6.html (failed)
http://timaltman.com/acid2/test014-7.html (failed, although not visible on first sight)
http://timaltman.com/acid2/test014-8.html (failed, like the previous)
http://timaltman.com/acid2/test014-9.html (failed, 1px off).

This is a problem with border painting order. The big problem is that the painting order is not clearly defined in any specification. I will file a separate bug on this.
Comment 105 Gábor Stefanik 2006-07-04 12:59:07 PDT
Filed bug 343583 on the nose issue.
Comment 106 Haudy Kazemi 2006-07-10 14:51:12 PDT
(In reply to comment #104 by Stefanik Gábor)
> Just noticed another issue, that is present even on the reflow branch: The nose
> is 1px off to the right and 1px up. A similar issue was also encountered and
> fixed by the Opera team (read more at http://weblog.timaltman.com/node/802 ).
> They have also created some testcases that might help fixing this bug.
> 
> http://timaltman.com/acid2/test014-1.html (passed)
> http://timaltman.com/acid2/test014-2.html (failed)
> http://timaltman.com/acid2/test014-3.html (failed)
> http://timaltman.com/acid2/test014-4.html (passed)
> http://timaltman.com/acid2/test014-5.html (failed)
> http://timaltman.com/acid2/test014-6.html (failed)
> http://timaltman.com/acid2/test014-7.html (failed, although not visible on
> first sight)
> http://timaltman.com/acid2/test014-8.html (failed, like the previous)
> http://timaltman.com/acid2/test014-9.html (failed, 1px off).

These seem to work for me on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

Your latest report on bug 343583 says that http://timaltman.com/acid2/test014-5.html only affects Cairo builds; were you using a Cairo build when you filed this comment?
Comment 107 Krzysztof Pawlik 2006-07-14 03:20:17 PDT
Just tested fireflowfox-3.0.reflow_20060603_branch.060703-1300 on Windows XP, got that result: http://www.nelchael.net/varia/fireflowfox.png - looks ok. But try to change window size: http://www.nelchael.net/varia/fireflowfox-error.png - and that's not ok.
Comment 108 Vitaly Harisov 2006-07-14 05:19:49 PDT
(In reply to comment #107)
> Just tested fireflowfox-3.0.reflow_20060603_branch.060703-1300 on Windows XP,
> got that result: http://www.nelchael.net/varia/fireflowfox.png - looks ok. But
> try to change window size: http://www.nelchael.net/varia/fireflowfox-error.png
> - and that's not ok.

http://www.webstandards.org/action/acid2/guide/

Row 1

This row is the scalp of the face and it tests fixed positioning, minimum and maximum heights, and minimum and maximum widths. In the markup, the row is represented by a p element which is fixed to the window rather than the scrollable canvas. If the Acid2 page is scrolled, the scalp will stay fixed in place, becoming unstuck from the rest of the face, which will scroll.
Comment 109 Krzysztof Pawlik 2006-07-14 05:35:00 PDT
(In reply to comment #108)
> This row is the scalp of the face and it tests fixed positioning, minimum and
> maximum heights, and minimum and maximum widths. In the markup, the row is
> represented by a p element which is fixed to the window rather than the
> scrollable canvas. If the Acid2 page is scrolled, the scalp will stay fixed in
> place, becoming unstuck from the rest of the face, which will scroll.

A.. right :)
Comment 110 Andras Keri 2006-10-18 02:51:59 PDT
Is it normal that Firefox2 RC3's rendering has nothing to do with the reference image?
Comment 111 James Ross 2006-10-18 02:58:12 PDT
Given that the work needed to make the face 'work' is all being done on trunk (and the reflow branch, a branch of trunk), there should be no reason to expect Firefox 2 to get it right. You'll have to wait for Firefox 3 to see it.
Comment 112 Worcester12345 2006-10-18 11:58:22 PDT
(In reply to comment #111)
> Given that the work needed to make the face 'work' is all being done on trunk
> (and the reflow branch, a branch of trunk), there should be no reason to expect
> Firefox 2 to get it right. You'll have to wait for Firefox 3 to see it.
> 

It doesn't work on a nightly trunk build of "Seamonkey", though it does come pretty close. I don't see a "reflow branch" anywhere, nor any documention of same.
Comment 113 Gábor Stefanik 2006-10-18 12:06:30 PDT
The fixed builds come from the reflow branch, the trunk builds are still slightly broken. (Read more about the reflow branch at http://wiki.mozilla.org/Gecko:Reflow_Refactoring).
Comment 114 Gábor Stefanik 2006-11-16 11:59:57 PST
If you are wondering why my reflow branch build site is producing a DNS error, that's because it has been moved to http://fireflowfox.ifastnet.com
Comment 115 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2006-11-16 12:05:44 PST
We're producing reflow branch nightly builds built the same way as the official Windows nightlies at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/reflow-refactor/
as described in http://wiki.mozilla.org/Gecko:Reflow_Refactoring#Quick_Links
Comment 116 Gábor Stefanik 2006-11-16 12:08:10 PST
I know, just these builds are a bit different, mainly in that they have a modified installer that doesn't overwrite trunk installations.
Comment 117 Derick Eisenhardt 2006-11-30 10:15:16 PST
It's really embarrassing that we still can't pass this test. As one of the most widely known open source browsers, we should always strive to pass any standards test will flying colors.
Comment 118 Nickolay_Ponomarev 2006-11-30 10:39:58 PST
> It's really embarrassing that we still can't pass this test. As one of the most
> widely known open source browsers, we should always strive to pass any
> standards test will flying colors.

Why? (Please reply to http://forums.mozillazine.org/ and stop adding non-technical comments to this bug.)
Comment 119 Gábor Stefanik 2006-11-30 13:39:47 PST
Also, we do have passing versions, although experimental. Those are the reflow branch builds. Once that branch is landed and the resulting version (Firefox 3) leaves beta, we will pass.
Comment 120 Worcester12345 2006-11-30 15:33:49 PST
Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061130 SeaMonkey/1.5a, it looks pretty close, but if you resize the window to something smaller, it changes. Then hit refresh and the top of the head turns orange sometimes. Hope that helps in some small way.
Comment 121 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2006-12-08 14:52:21 PST
Last bugs fixed on trunk by reflow branch landing.
Comment 122 Marek Stępień [:marcoos, inactive] 2006-12-08 15:31:54 PST
Verified with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/2006120804 Minefield/3.0a1

Whoa! :)
Comment 123 Matp75 2006-12-08 15:57:48 PST
Created attachment 248025 [details]
acid2 screenshot after resize

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061208 Minefield/3.0a1 (latest trunk on ftp.mozilla.org, new profile)
looks great at first sight.
but when I resize the window to a small size and I grow it again, it's broken.
Comment 124 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2006-12-08 18:07:08 PST
That looks like you've scrolled to a different position, and if you scroll to the #top anchor again it would work correctly.  That said, we ought to preserve the position when you do something like that...
Comment 125 Scott Tankard 2006-12-08 18:19:40 PST
(In reply to comment #124)
> That looks like you've scrolled to a different position, and if you scroll to
> the #top anchor again it would work correctly.  That said, we ought to preserve
> the position when you do something like that...
> 

I'm not using the said build, so I can't really be sure, but might #1 be applicable? : http://www.webstandards.org/2006/07/20/acid2-and-opera-9-clarifications/

Changing when you scroll sounds right, but not the resizing the window bit...

In another tone, are we really sure there are no little bugs lurking behind the closet on this? Is it really passed?
Comment 126 Jesse Ruderman 2006-12-08 21:30:38 PST
On both Windows and Mac, the scalp appears detached if the window is less than about 800 pixels wide.  The "Hello World" text moves down too!  It doesn't seem to be an incremental-reflow bug; reloading at the same window size doesn't affect the rendering either way.  Scrollbars do not appear.

If I make the window even narrower on Mac (about 500 pixels wide), the "Hello world" text and the bulk of the head move down again, making it look like Amaran's screenshot.  But again, resizing the window back to normal size makes it look fine again.

Is this expected?
Comment 127 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2006-12-08 21:52:15 PST
(In reply to comment #126)
> On both Windows and Mac, the scalp appears detached if the window is less than
> about 800 pixels wide.  The "Hello World" text moves down too!  It doesn't seem
> to be an incremental-reflow bug; reloading at the same window size doesn't
> affect the rendering either way.  Scrollbars do not appear.

Even though scrollbars don't appear, please remember that you're scrolled down a few pages and there's text above what you're looking at -- and that text can wrap.  What you're seeing is that our memory of scroll position when text rewraps is relative to the top of the page.  Try hitting enter in the URL bar again at the new width -- you'll scroll to the anchor's new position.
Comment 128 Scott Tankard 2006-12-08 23:17:28 PST
(In reply to comment #126)
> On both Windows and Mac, the scalp appears detached if the window is less than
> about 800 pixels wide.  The "Hello World" text moves down too!  It doesn't seem
> to be an incremental-reflow bug; reloading at the same window size doesn't
> affect the rendering either way.  Scrollbars do not appear.
> 
> If I make the window even narrower on Mac (about 500 pixels wide), the "Hello
> world" text and the bulk of the head move down again, making it look like
> Amaran's screenshot.  But again, resizing the window back to normal size makes
> it look fine again.
> 
> Is this expected?
> 

Yes, it is expected; it has to do with fixed positioning in the test. Opera does this, and in a clarification published on the WaSP site it was confirmed it was correct.

I repeat: the top of the head is supposed to separate from, the rest of the face when scrolling.

See: http://www.webstandards.org/2006/07/20/acid2-and-opera-9-clarifications/ and http://www.webstandards.org/2006/07/13/acid2-and-opera-9-problems/
Comment 129 Matp75 2006-12-09 01:29:17 PST
At full window size, if I open the acid2 test in the first tab and the reference test in the second tab and switch between the two tabs, I see everything exactly the same except the nose position. Firefox'nose is a few pixel at the left and top compared to the reference nose.
Is this correct ?
(win xp sp2, 1024*768)
Comment 130 Gábor Stefanik 2006-12-09 02:47:17 PST
It is not really correct, but neither is the reference rendering. The final version of Firefox 3 will render the nose antialiased (once bug 328241 is fixed).
Comment 131 Jesse Ruderman 2006-12-09 04:34:34 PST
Thanks for explaining the cause of the resizing problem.  I guess it's basically bug 19261, "When resizing the window, need to keep place in content".  Fixing that bug is difficult due to complex web site layouts such as multi-column layouts, and isn't required for acid2 compliance.

In a comment on http://www.webstandards.org/2006/07/20/acid2-and-opera-9-clarifications/, Hixie suggested a solution that would help with resizing on the acid2 page: "if you're at a fragment identifier and you resize the window, the page should arguably remain at that fragment identifier".  But that doesn't solve the problem for most web pages.
Comment 132 Worcester12345 2006-12-11 15:36:15 PST
(In reply to comment #120)
> Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061130
> SeaMonkey/1.5a, it looks pretty close, but if you resize the window to
> something smaller, it changes. Then hit refresh and the top of the head turns
> orange sometimes. Hope that helps in some small way.
> 

Still doing it, only now I am noticing a rectangle around the eyes changes to orange and red momentarily when you hit reload. And it also leaves a white space with the top of the head a little higher up. This is with the latest Windows version which is:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061209 SeaMonkey/1.5a
Comment 133 Zibi Braniecki [:gandalf][:zibi] 2007-01-01 10:19:51 PST
rv: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a2pre) Gecko/20070101 Minefield/3.0a2pre

We've got a regression in latest trunk. There's a red block below the face. Is there a bug for it already that I missed, or should I file one?
Comment 134 Gábor Stefanik 2007-01-01 10:36:56 PST
I can't repro in today's Windows build, probably Linux-specific. Strangely in the 20061228 build, Acid2 has a red "beard" (CSS tables bug), but 20070101 Win displays it correctly.
Comment 135 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2007-01-01 10:59:41 PST
The regression was bug 365191.  It's already fixed.
Comment 136 Zibi Braniecki [:gandalf][:zibi] 2007-01-02 09:42:33 PST
Created attachment 250180 [details]
possible regression

I rebuilt it today, and still see this.

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a2pre) Gecko/20070102 Minefield/3.0a2pre
Comment 137 Zibi Braniecki [:gandalf][:zibi] 2007-01-02 10:02:19 PST
I see the same on FTP build from ftp.mozilla.org.
Comment 138 Marek Stępień [:marcoos, inactive] 2007-01-02 10:26:08 PST
WFM, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/2007010204 Minefield/3.0a2pre
Comment 139 Filip Jirsák 2007-02-10 05:41:23 PST
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2) Gecko/20070206
GranParadiso/3.0a2 doesn't pass Acid2 test because of bug #352937 See http://www.jirsak.org/gecko/bug?acid2=frame
Comment 140 Scott Baker 2007-02-10 08:03:30 PST
I'm running the same version as you are and the official Acid2 test displays just fine. The link you provided has some weird error on the right side though, while the left is fine. Perhaps you can explain the link you posted a little better? My understanding is that Acid2 compliance is complete.
Comment 141 Filip Jirsák 2007-02-10 08:30:19 PST
(In reply to comment #140)
The link I provided use the same HTML code like the official Acid2 test – the HTML code is copied. You can check this by comparing HTML source. The difference between left and right side is in way how they are send to browser. Left frame is send as fast as possible. But right frame is send with delay between sending lines  139 and 140 – between two elements, which have style display:table-cell.

I think Gecko starts drawing of page at some time. When the page is loaded complete at this time, it is drawn correct. But when page is only half-loaded, Gecko draws what it knows. After next part of page arrives, it should be drawn. But when the break between two parts is in "virtual" table (between two elements with display:table-cell) Gecko starts drwaing table-cell after page break on a new row of "virtual" table.

There is second testcase in bug #352937
http://www.jirsak.org/gecko/bug and http://www.jirsak.org/gecko/bug?pause=true

It is simpler then Acid2 and show exactly what occurs: both source code is the same, and all items 1 to 10 should be in one line. But when there is delay between Firefox gets two items, it draws second item on new line. You can observe it: the items 1 to 5 are drawn first, than there is 1 second delay and than items 6 to 10 are drawn, but on the new line.

It can occurs randomly when connection lags, there are some testcases within bug #352937 which can simulate this (it forces delay between sending line 139 and 140 of Acid2 test HTML source).

I will append complete ready-to-run testcase for bug #352937 in a few moments.

Comment 142 Filip Jirsák 2007-02-10 09:11:20 PST
Created self-contained ready to run testcase for testing on local computer. You need only Java Runtime Environment (JRE) version 5.0 or higher – see http://java.sun.com/javase/downloads/index.jsp

Than download testcase.jar from http://www.jirsak.org/gecko/testcase.jar and run

java -jar testcase.jar

or

java -Djetty.port=8081 testcase.jar

if you want to run web server on different port (default is 8080).

Then point browser to http://localhost:8080/ and you can test.
Comment 143 Filip Jirsák 2007-02-11 02:16:52 PST
New testcase which works in standalone HTML, you don't need webserver:

https://bugzilla.mozilla.org/attachment.cgi?id=254716&action=edit
Comment 144 Worcester12345 2007-02-12 17:06:34 PST
Will there be an Acid3 test?
Comment 145 Sierk Bornemann 2007-04-17 18:26:51 PDT
The Acid 2 test on http://www.webstandards.org/files/acid2/test.html isn't rendered properly by Firefox Nightly Build (Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a4pre) Gecko/20070415 Minefield/3.0a4pre).

Most of the black blocks forming the outline of the face are 2 pixels higher in shape than in the reference picture, two black blocks (left and right) in the lower third of the face outline even are about 6 pixels higher than in the reference picture. The nose is rendered about 1 pixel smaller on 3 edges, somewhat like that there is a border with the same color not drawn completely around the black square but only on one edge of the nose. 

Maybe this issue is tight related with Bug 328241 (which is still open at this time of writing), but I am unsure about this guess.

Nevertheless -- it would be fine, if this issue would be fixed before giving Bug 289480 the final status "fixed". I mean, the face of the Acid 2 test should be rendered *exactly* like the reference picture, not reasonably and not approximately but exactly.
Comment 146 Jesse Ruderman 2007-04-17 18:40:18 PDT
That's a recent regression and you should file a new bug (blocking this one).  I see it too.  I don't think it's bug 328241.
Comment 147 Sierk Bornemann 2007-04-17 18:49:17 PDT
Why file a new bug? Why not just reopen bug 289480 and allocate the appropriate status?
Comment 148 Jesse Ruderman 2007-04-17 18:55:12 PDT
This has always been a metabug, tracking the actual bugs that affect acid 2 rendering.
Comment 149 philippe (part-time) 2007-04-17 19:04:34 PDT
(In reply to comment #145)

1. The nose issue is a case of bad border painting, I think. Bug 368247 should improve that.
2. The size of the black blocks: If you have a minimum font-size set then those will be taller. The test requires a default setting, as has been commented before on this page. With no-minimum the whole image displays correctly on my side, except for the nose issue.
Comment 150 Sierk Bornemann 2007-04-17 19:10:01 PDT
Is this meta bug filed and has got a bug number? If so, why isn't it a blocker for Bug 289480? Why is Bug 289480 marked as "Fixed", when it seems that there obviously are issues with passing Acid 2 test *exactly*?
Comment 151 Colin Snover 2007-04-17 19:15:27 PDT
Sierk, this bug, Bug 289480, *is* the meta-bug for Acid2. Jesse wanted you to create a new bug report for the specific problem you are experiencing and to file it as blocking this bug.
Comment 152 Sierk Bornemann 2007-04-17 19:35:39 PDT
Philippe, thanks for the tip with minimum font-size. Disabling it (default setting) makes the rendering better, but the most top black bar of the outline, still renders 2 pixel too low as it should. I played with different fonts (from Helvetica to Arial to Times New Roman) on my preference pane of Firefox, but without positive effect to this issue. The black outline is still not exactly rendered as it should be. If solving Bug 368247 does really fix the misrendering of the nose, why isn't it a blocker for Bug 289480? Phillippe, could you please make it a blocker, if you are sure?

If anybody here can give me a reason, why the most top bar of the face's outline is still not rendered correctly on my side (although I use the default settings), then I will file a new bug concerning this and blocking Bug 289480. 
Comment 153 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2007-04-17 19:48:34 PDT
The nose is not misrendered.  See bug 343583 comment 6.
Comment 154 Sierk Bornemann 2007-04-17 20:42:47 PDT
Firstly, after reading carefully Bug 343583, I have to accept and concede the different rendering of the test's nose, dependend on the browser's implementation of rendering borders.

Secondly, I have just disabled my Firefox profile and let Firefox create a plain vanilla default profile to ensure optimal premises to run the Acid2 test again.

Result of my test:
Still a glitch with the lower left border of the nose. This issue might depend on Bug 368247, which should be made a blocker for Bug 289480.
Still issues painting the borders correctly. Relying on the browser's default preferences (especially with the option "Allow pages to choose their own fonts, instead of my selections above" being checked per default), nearly all black outline borders (like I stated before) are painted a few pixels taller than they should. Couriously this issue improves, if I uncheck the default checked preference option "Allow pages to choose their own fonts, instead of my selections above". In that case, only the upper top black block of the outline is rendered 2 pixels too low, the rest of the outline blocks are rendered correct.

Conclusion: this bug 289480 doesn't fulfill my claim, a bug should fulfill to be marked as "Fixed". It should be re-opened to clarify, what's going on there. What do you mean, guys?
Comment 155 Sierk Bornemann 2007-04-17 20:45:56 PDT
Firstly, after reading carefully Bug 343583, I have to accept and concede the
different rendering of the test's nose, dependend on the browser's
implementation of rendering borders.

Secondly, I have just disabled my Firefox profile and let Firefox create a
plain vanilla default profile to ensure optimal premises to run the Acid2 test
again.

Result of my test:
Still a glitch with the lower left border of the nose. This issue might depend
on Bug 368247, which should be made a blocker for Bug 289480.
Still issues painting the borders correctly. Relying on the browser's default
preferences (especially with the option "Allow pages to choose their own fonts,
instead of my selections above" being checked per default), nearly all black
outline borders (like I stated before) are painted a few pixels taller than
they should. Couriously this issue improves, if I uncheck the default checked
preference option "Allow pages to choose their own fonts, instead of my
selections above". In that case, only the upper top black block of the outline
is rendered 2 pixels too low, the rest of the outline blocks are rendered
correct.

Conclusion: this bug 289480 doesn't fulfill my claim, a bug should fulfill to
be marked as "Fixed". It should be re-opened to clarify, what's going on there.
Your opinions, guys?
Comment 156 Gábor Stefanik 2007-04-18 05:32:32 PDT
Sounds like we've got a regression here. Could you attach a screenshot? (Note that you might be seeing a rounding error, or, judging from the font override issue, a wrong default font. Note that the test was originally designed with Windows fonts in mind, and Mac seems to choose a wrong substitute font.)
Comment 157 Nickolay_Ponomarev 2007-04-18 07:30:52 PDT
(In reply to comment #155)
> Conclusion: this bug 289480 doesn't fulfill my claim, a bug should fulfill to
> be marked as "Fixed". It should be re-opened to clarify, what's going on there.
> Your opinions, guys?
> 
The way we work is: mark the bug as fixed, when a known check-in fixed the bug (in this case it was the landing of the reflow branch - see comment 121). If there are regressions, we don't reopen the original bug, but instead file new bugs on the regressions. This bug is too long to be usable by the developer who will work on fixing the regression.
Comment 158 Sierk Bornemann 2007-04-18 12:08:53 PDT
Filed Bug 377928 with a blocker to Bug 289480.
Comment 159 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2007-04-18 12:12:57 PDT
*** Bug 377928 has been marked as a duplicate of this bug. ***
Comment 160 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2007-04-18 12:14:51 PDT
Reopening to make people happy.
Comment 161 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2007-04-18 12:25:16 PDT
(In reply to comment #157)
> The way we work is: mark the bug as fixed, when a known check-in fixed the bug
> (in this case it was the landing of the reflow branch - see comment 121). If
> there are regressions, we don't reopen the original bug, but instead file new
> bugs on the regressions. This bug is too long to be usable by the developer who
> will work on fixing the regression.

That doesn't apply in this case, since this is a tracking bug.  New bug reports should be filed for specific issues, but we only need one tracking bug, and specific issues should *not* be discussed in the tracking bug, since nobody will ever find them.
Comment 162 Sierk Bornemann 2007-04-18 12:38:12 PDT
I have relied to the status "Fixed" of Bug 289480 and have been disappointed,
that this information doesn't seem to be true relating MacOSX. So, I have
tested and filed this bug to point the attention to this issue again. Before
the news spreads around the world, that Firefox at long last passes the Acid 2
test, we should assure, that this truely is the case for any supported
platform. In any case not fulfilling the needs, Bug 289480 should not be marked
as "Fixed" to avoid any false expectation.
Comment 163 Nickolay_Ponomarev 2007-04-18 12:43:31 PDT
David, right, I didn't suggest filing a separate _meta_ bug. The reason I didn't want to reopen this one is that toggling the state of this bug sends e-mails to the people in dependent bugs, which is a lot of spam.

Perhaps the next time this bug is closed it should be marked invalid, so that people don't reopen it each time we have a layout regression :)
Comment 164 石庭豐 (Seak, Teng-Fong) 2007-05-19 06:56:02 PDT
I suggest that using this guide: http://www.webstandards.org/action/acid2/guide/
we divide this bug into smaller bugs, each for each row (or group of rows) and try to fix them one by one.

This should make management of this bug easier.
Comment 165 Nickolay_Ponomarev 2007-05-21 02:23:49 PDT
*** Bug 377928 has been marked as a duplicate of this bug. ***
Comment 166 nathaniel 2007-08-19 12:16:48 PDT
Zoom out causes an orange bar to appear around the guy's eyes.
Comment 167 Filip Jirsák 2007-09-24 08:46:39 PDT
Shouldn't be Bug 352937 marked as blocker to this bug?
Comment 168 Worcester12345 2007-09-28 07:08:35 PDT
(In reply to comment #166)
> Zoom out causes an orange bar to appear around the guy's eyes.
> 

If I zoom to 200%, it shows just orange.

Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007092802 SeaMonkey/2.0a1pre
Comment 169 Taral 2007-09-28 18:20:33 PDT
Reflow-type operations like zoom do not count for acid2.
Comment 170 Scott Baker 2007-12-19 15:48:28 PST
Firefox 3 Beta 2 (at least on Linux) doesn't pass the acid 2 test anymore. I just tried Beta 1 yesterday, and it worked fine, but Beta 2 has problems. It appears both of the eyes are broken with Beta 2. Can someone else confirm? This is with a fresh profile and everything.
Comment 171 Paulo Raponi 2007-12-19 15:55:27 PST
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2


Firefox 3 Beta 2 in Windows Vista doesn't pass too
Comment 172 Hixie (not reading bugmail) 2007-12-19 16:03:57 PST
The site broke. I'm reporting it. Let me know if the Acid2 test still doesn't pass after the new year.
Comment 173 Colin Guthrie 2007-12-19 16:10:33 PST
(In reply to comment #172)
> The site broke. I'm reporting it. Let me know if the Acid2 test still doesn't
> pass after the new year.
> 

Maybe MS just asked for the site to be changed slightly so they could take a couple of screenshots...... http://blogs.msdn.com/ie/archive/2007/12/19/internet-explorer-8-and-acid2-a-milestone.aspx
Comment 174 Masahiro YAMADA 2007-12-19 17:27:50 PST
(In reply to comment #172)
> The site broke. I'm reporting it. Let me know if the Acid2 test still doesn't
> pass after the new year.
> 
I agree because Opera 9.50beta (build 9613) on Windows 2000 doesn't pass too.
And its result seems to be same as result fo Firefox Trunk.
Comment 175 Ryan VanderMeulen [:RyanVM] 2007-12-19 17:30:56 PST
Hixie's the person who wrote the test ;-)
Comment 176 James Justin Harrell 2007-12-19 18:42:25 PST
What changed that broke the test?

It looks like an object element that's pointing to a non-existent page (http://www.webstandards.org/404/) should be falling through, but that page is now returning a response status of 200 (success) instead of 404. Was it previously correctly returning a 404 response?

Perhaps this test should be hosted on a separate server, instead of coexisting with a live site like WebStandards.org, so that future mishaps like this don't happen.
Comment 177 Hixie (not reading bugmail) 2007-12-19 19:35:38 PST
Yes, that's the error.

The test is also hosted on my site:
   http://www.hixie.ch/tests/evil/acid/002/
Comment 178 Andrew Listochkin 2007-12-20 05:17:27 PST
Hey, that's childish!
I’ve just came to Acid and passed it – I use Opera 9.24 :)
That fake page talks reminds me fake Moon landing talks.
Regards.
Comment 179 Gábor Stefanik 2007-12-20 05:51:46 PST
The hixie.ch verson passes, the webstandards.org one doesn't. It looks like a server issue, http://www.webstandards.org/404/ seems to send a HTTP/200 status code (that is, all's well) instead of the expected HTTP/404 (page not found). Most probably they made changes to the site, breaking many links coming from outside, and decided to make an error page, telling visitors that the incoming links are broken because of the reorganization. The problem is that they placed the error page at http://www.webstandards.org/404/, which is, coincidentally, the "invalid" URL they used in Acid2 before. The version of hixie.ch seems to use an invalid damowmow.com url instead. (A sidenote: reference.png is out of date, it should show an antialiased nose, like in Firefox.)
Comment 180 Jeff Walden [:Waldo] (remove +bmo to email) 2007-12-20 14:26:14 PST
Created attachment 294105 [details] [diff] [review]
Reftest

This depends on the patch in bug 409293, as well as a to-be-posted image for the smiley.  (The one in the acid2 reference itself doesn't work due to nose positioning, so I had to make one that was pixel-accurate with the current Gecko rendering.)
Comment 181 Jeff Walden [:Waldo] (remove +bmo to email) 2007-12-20 14:30:05 PST
Created attachment 294110 [details]
Reference smiley for reftest
Comment 182 Rhi Bigner 2007-12-21 15:20:41 PST
(In reply to comment #179)
> The hixie.ch verson passes

http://img120.imageshack.us/img120/4421/ff3acid2ob8.png
Comment 183 Vlado Valastiak [:wladow] @ Mozilla.sk 2007-12-22 03:15:40 PST
Seems webstandards.org test is fixed now, both FX3.0b3pre and Opera 9.5b pass it again.
Comment 184 Gábor Stefanik 2007-12-22 05:29:34 PST
Rhi: can you reproduce your issue? On Mac, it passes fine, maybe Vista-only. (Also, check your font settings, they should be set to defaults.)
Comment 185 Majken Connor [:Kensie] 2007-12-23 10:50:27 PST
(In reply to comment #182)
> (In reply to comment #179)
> > The hixie.ch verson passes
> 
> http://img120.imageshack.us/img120/4421/ff3acid2ob8.png
> 

Bug 400813
Comment 186 Vivek Nair 2007-12-26 01:00:13 PST
(In reply to comment #183)
> Seems webstandards.org test is fixed now, both FX3.0b3pre and Opera 9.5b pass
> it again.
> 

Confirmed
Comment 187 Ömer Fadýl USTA 2008-01-09 22:16:51 PST
I think FX3.0b3pre (10/01/08) couldn't pass the test because
it is printing nose blue whether the cursor on the nose and if mouse cursor will be the same high. On the other hand it must be make nose blue if and only if the mouse cursor is on nose ( not outside of nose )

Here the proof :
http://img134.imageshack.us/img134/7573/acid2qn4.png
Comment 188 Jeff Walden [:Waldo] (remove +bmo to email) 2008-01-09 23:47:08 PST
The cursor doesn't need to be over the nose; rather, it needs to be over the yellow, widest-width horizontal rectangle on the face (the one which contains the square of the nose).  Do also be careful about which pixel is the hot spot on your cursor, to make sure you're not basing this on a wrong assumption of which pixel activates hovering (move the cursor to a corner of the screen to check).

There's no reason for people to be commenting on this bug any more complaining about failures.  If such failures happen, please file new bugs; this one served its purpose in tracking work to fix acid2 on trunk, and new failures represent new issues which should be tracked separately.

DO NOT COMMENT ON THIS BUG TO REPORT REGRESSIONS.
Comment 189 Gábor Stefanik 2008-01-10 12:52:00 PST
(In reply to comment #187)
> I think FX3.0b3pre (10/01/08) couldn't pass the test because
> it is printing nose blue whether the cursor on the nose and if mouse cursor
> will be the same high. On the other hand it must be make nose blue if and only
> if the mouse cursor is on nose ( not outside of nose )
> 
> Here the proof :
> http://img134.imageshack.us/img134/7573/acid2qn4.png
> 
This is not a bug. The nose is supposed to turn blue when hovered. In fact, 3 wrong outcomes are possible for the nose (if it is rendered at all):
1. The hover effect doesn't work. That is, the nose stays black when hovered. This would actually be wrong, it *should* turn blue, and it does turn blue.
2. The nose is blue all the time. Also wrong, but no browser suffers from this bug.
3. The nose turns red instead of blue when hovered. This happens on Opera 8, but not on Opera 9.
So, we essentially do pass the test. However, in some situations, it might still fail, that's why this bug is open.
Comment 190 boiert 2008-03-05 08:51:14 PST
Ok, I'm not sure how to report this,

Using Firefox 3 Beta 3 on Windows XP
When zooming out on the acid2 rendering test page, a few bugs appear, these bugs persist even when the zoom is reset.

Also, the second to last line is 1 block too high.
Comment 191 Ray Kiddy 2008-03-05 09:55:44 PST
There are probably a few ways to report this.

1) Capture the source and a screenshot of what you see, verify that a local copy of the source, when loaded in the browser, shows the problem and attach them to the bug.

2) If you can create a page, with different source, that shows the page without the errors, you can create a reftest and a reftest failure will give you the data URL for both images, which could then be attached to a bug.

3) Use the Help->Report Broken Web Page menu item. I am not sure how to connect something from the problem report generated by that menu to a bugzilla bug, but I have not experimented with it much.

4) others? Maybe.
Comment 192 David Naylor 2008-03-05 14:48:43 PST
(In reply to comment #190)
> Ok, I'm not sure how to report this,
> 
> Using Firefox 3 Beta 3 on Windows XP
> When zooming out on the acid2 rendering test page, a few bugs appear, these
> bugs persist even when the zoom is reset.

I see some rendering problems when zooming in, but they disappear when zooming out. (Using the latest nightly.)
> 
> Also, the second to last line is 1 block too high.
> 
Not in the latest nightly build. I just checked against a 12 px grid in Photoshop.
Comment 193 -fullmetaljacket- 2008-03-05 23:55:09 PST
(In reply to comment #190)
> Ok, I'm not sure how to report this,
> 
> Using Firefox 3 Beta 3 on Windows XP
> When zooming out on the acid2 rendering test page, a few bugs appear, these
> bugs persist even when the zoom is reset.

from http://www.webstandards.org/action/acid2/guide/

"Note: When taking the test, you should use the default settings of the browser you are testing. Changing the zoom level, minimum font size, applying a fit-to-width algorithm, or making other changes may alter the rendition of the Acid2 page without this constituting a failure in compliance. (Added 21 July 2006)"

Comment 194 boiert 2008-03-06 00:22:26 PST
Created attachment 307664 [details]
acid2 test result The stange double height line
Comment 195 boiert 2008-03-06 00:23:24 PST
Created attachment 307665 [details]
acid2 test result The zooming bug
Comment 196 boiert 2008-03-06 00:24:08 PST
Created attachment 307666 [details]
acid2 test result The zooming bug persists
Comment 197 Unknown W. Brackets 2008-03-06 00:28:21 PST
(In reply to comment #194)
> Created an attachment (id=307664) [details]
> acid2 test result The stange double height line
> 

Have you tried creating a new profile to ensure it isn't caused by your settings?

(In reply to comment #196)
> Created an attachment (id=307666) [details]
> acid2 test result The zooming bug persists
> 

Please read comment #193.  The Acid2 test is simply not written for zooming; it is not necessarily incorrect for it to be broken by zooming.  Different tests are written different ways, for different things.

-[Unknown]
Comment 198 David Naylor 2008-03-06 00:39:09 PST
(In reply to comment #196)
> Created an attachment (id=307666) [details]
> acid2 test result The zooming bug persists
> 

Well, as I said above, this bug is not present in the latest nightlies.
Comment 199 boiert 2008-03-06 01:42:22 PST
Created attachment 307670 [details]
acid2 test result The zooming bug animation

Then why is there a discrepancy between zooming in a loaded page, and reloading a page at that same zoom level.

This will be an issue for Firefox mobile
Comment 200 Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m) 2008-03-30 07:08:40 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008032904 Minefield/3.0pre

I noticed the "nose" has the outlines a bit blurred. I test it with a blank profile
Comment 201 Tuukka Tolvanen (sp3000) 2008-03-30 07:19:05 PDT
> I noticed the "nose" has the outlines a bit blurred. I test it with a blank

Search for "nose" in the preceding comments on this bug, please.
Comment 202 Bruno Lustosa 2009-04-08 07:54:23 PDT
Hello.

Although work on acid3 is progressing alot, as of today, Minefield nightly is not passing Acid2 anymore. The "chin" is red.
Here's what I use:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090407 Minefield/3.6a1pre

I'll attach a screenshot from here.
Comment 203 Bruno Lustosa 2009-04-08 07:57:14 PDT
Created attachment 371676 [details]
Broken acid2 on minefield nightly (2009-04-07)
Comment 204 Steve England [:stevee] 2009-04-08 08:01:23 PDT
Bruno see http://whereswalden.com/2009/02/20/when-good-tests-go-bad-firefox-on-acid2/
Comment 205 Dave Garrett 2009-04-08 08:01:23 PDT
(In reply to comment #202)
> Although work on acid3 is progressing alot, as of today, Minefield nightly is
> not passing Acid2 anymore. The "chin" is red.

This is well known.
http://whereswalden.com/2009/02/20/when-good-tests-go-bad-firefox-on-acid2/
Comment 206 Bruno Lustosa 2009-04-08 08:11:17 PDT
Yes, I see. Sorry for taking your time.
I did a search for acid2, and couldn't find anything related. As we have all the fuss around getting firefox to pass acid3, thought people might have overlooked this.
Again, sorry and thanks for the reference. It's good to know it's failing, even if it's the test's fault.
Comment 208 Worcester12345 2014-01-08 09:12:53 PST
Is it just me, or is this broken again?
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20140107004003 CSet: 71ad7ff30010
Comment 209 Ryan VanderMeulen [:RyanVM] 2014-01-08 09:15:11 PST
WFM on trunk. BTW, we have an automated reftest for this, so regressions would be caught pretty fast:
http://mxr.mozilla.org/mozilla-central/source/layout/reftests/bugs/289480.html
Comment 210 Scott Baker 2014-01-08 09:27:08 PST
I'm using 26.0 on Linux and the Acid2 is indeed broken. Acid3 is still fine.
Comment 211 Scott Baker 2014-01-08 09:28:59 PST
As an additional note Chrome 31 is also broken for the Acid2 test. There is a scrollbar where the eyes should be. It appears FF26 and Chrome 31 are broken in the same way.

Is the Acid2 test still relevant?
Comment 212 Laurent Jouanneau 2014-01-09 05:20:10 PST
I confirm that it is broken

- on my Linux (Mint 15 KDE) laptop, with FF26, FF nighlty, and Chromium 31
- on Windows XP (in VirtualBox) with FF26, and Google Chrome 31

Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0
Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0

Note that I don't have exactly same issues between http://mxr.mozilla.org/mozilla-central/source/layout/reftests/bugs/289480.html and http://www.webstandards.org/files/acid2/test.html#top
Comment 213 philippe (part-time) 2014-01-09 05:35:23 PST
(In reply to Laurent Jouanneau from comment #212)

> http://mxr.mozilla.org/mozilla-central/source/layout/reftests/bugs/289480.
> html and http://www.webstandards.org/files/acid2/test.html#top

Both are broken with Safari 7, Opera 12, Chrome 33 dev and Firefox nightly running on OS X 10.9. The 2 tests render differently, but equally (bad) across the browsers.

I would assume there is something busted in the test files themselves.
Comment 214 Simon Sapin (:SimonSapin) 2014-01-12 10:22:05 PST
http://www.webstandards.org/act/acid2/test.html is broken because it relies on http://www.webstandards.org/404/ being a HTTP 404 error while it returns HTTP 200 at the moment.

layout/reftests/bugs/289480.html in the tree and http://acid2.acidtests.org/ do not have this issue and render fine.
Comment 215 angusprune 2015-10-14 17:09:33 PDT
ACID2 is no longer rendering correctly in firefox, chrome or edge. 
There is red hatching across the eyes.
http://postimg.org/image/e185uc2vx/
Comment 216 Simon Sapin (:SimonSapin) 2015-10-15 11:53:48 PDT
angusprune, do you have a "high DPI" monitor? It’s a known issue that Acid2 only renders correctly when one CSS px is one device pixel. Check layout.css.devPixelsPerPx is about:config and try setting it to 1.

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