Closed Bug 289480 (acid2) Opened 19 years ago Closed 5 years ago

[meta] Tracking bug for acid2 (acid 2) test

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: bugzilla1, Assigned: chofmann)

References

(Depends on 1 open bug, )

Details

(Keywords: meta, Whiteboard: [reflow-refactor])

Attachments

(19 files, 2 obsolete files)

13.84 KB, text/html; charset=UTF-8
Details
1.31 KB, text/html
Details
4.39 KB, image/png
Details
13.96 KB, text/html
Details
2.44 KB, image/png
Details
105.34 KB, image/png
Details
3.80 KB, image/png
Details
3.82 KB, image/png
Details
8.80 KB, image/jpeg
Details
37.16 KB, image/png
Details
18.59 KB, image/png
Details
16.69 KB, patch
Details | Diff | Splinter Review
5.94 KB, image/png
Details
36.93 KB, image/png
Details
33.88 KB, image/png
Details
37.19 KB, image/png
Details
184.97 KB, image/gif
Details
4.76 KB, image/png
Details
14.35 KB, text/html
Details
:-(

On the other hand, we're better than IE6 and Opera 8 :-)
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.
Assignee: nobody → chofmann
Component: Layout → Tracking
OS: Windows XP → All
QA Contact: layout → chofmann
Hardware: PC → All
dbaron - I'm wondering why you added 9458 to this, when the test doesn't use
inline-block?
Confirmed.  This is not good...

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

Being the BEST still doesn't make us right.
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
(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.
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.
Alias: acid2
Dupe of 286556.
(In reply to comment #7)
> Dupe of 286556.

No, totally different url
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
Adding info from #286556
Depends on: 243519, 285871
No longer depends on: 243519, 285871
Made the same mistake as in comments 7/8, d'oh.
Assignee: chofmann → dbaron
Priority: -- → P2
QA Contact: chofmann → ian
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).
Depends on: 290290
(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.
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.
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.
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 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).
Depends on: 191830, 290290
(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).
Please share. Those are members only posts.
Blocks: majorbugs
Depends on: 291126
The wasp made a guide explaining the acid2 test:
http://www.webstandards.org/act/acid2/guide.html
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."
*** Bug 291592 has been marked as a duplicate of this bug. ***
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.
Anybody want to simplify this and figure out which bug it is (or file a new
one, if needed)?
*** Bug 291710 has been marked as a duplicate of this bug. ***
See bug 291060 for details on how the baseline issue was resolved.
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.
Taral, can you simplify that a bit more and file a bug against me?
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
Depends on: 292295
*** Bug 292335 has been marked as a duplicate of this bug. ***
*** Bug 292513 has been marked as a duplicate of this bug. ***
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.
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.
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.
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...
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.
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.
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.
Flags: blocking-aviary1.1?
*** Bug 294818 has been marked as a duplicate of this bug. ***
just wanted to add that something regressed. The picture is now rendered worse.
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...)
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].
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.
No longer blocks: majorbugs
Attached file Full Acid2 Testcase
Adding the full Acid2 test in response to Comment #45
Added a new screenshot of the current Acid2 rendering, since the previous
screenshot was too good to be true.
Attachment #184965 - Attachment description: Current rendering of Acid2 (attached testcase) → Current rendering of Acid2 (and the attached testcase)
Attachment #184496 - Attachment description: Screenshot. → Screenshot (of attachment 181654.)
(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+
Not for the actual, full acid2 test. What you are looking at is a reduced testcase.

http://www.webstandards.org/act/acid2/test.html
*** Bug 296641 has been marked as a duplicate of this bug. ***
Depends on: 296648
Finally tracked down the bug with that small gap. Opened bug 296648, but can't
assign to Robert.
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
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.
(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.
(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.
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.
> Commenting/voting in bugs is our only way of getting
> attention from the real drivers.

it's an excellent way to annoy such people.
> 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.)
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)
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Bug 244135 shows up on the test tour page. Not strictly part of the test, but...
[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
> [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.
*** Bug 303233 has been marked as a duplicate of this bug. ***
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 ;)
Attached image Current renderring (obsolete) —
Nobody's given an updated image, so here you go.
Comment on attachment 198228 [details]
Current renderring

False alarm, it seems to have not changed much (or at all), even with bug 1156
fixed.
Attachment #198228 - Attachment is obsolete: true
What the current rendering truely is like in the trunk. By squashing that
latest bugs the eyes now render.
(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?
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).
Should this bug include "depends on" for Bug 312639 ?
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".
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
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?
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
(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.
I don't think that gecko's acid2 issues have anything to do with invalid markup. certainly not those of them that I know.
(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.
(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
In the 11/27 Mozilla Suite build, it puts in the green eyes after a reload/refresh, but not in Firefox. Both in branch.
FYI: Current rendering in firefox trunk builds after the latest checkin.
*** Bug 320703 has been marked as a duplicate of this bug. ***
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. :(
(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?
(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

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.
Resize the window, I didn't want to upload more than necessary.
Flags: blocking1.9a1?
Shows the progress made after bug 317375 (frame display lists) landed.
Attached image IE7 beta 2 preview rendering (obsolete) —
(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. ;)
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
Attachment #210373 - Attachment is obsolete: true
Flags: blocking-aviary1.5-
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!
Stefanik, see bug 328241. This is a cairo bug.
Looks like the latest Opera build passes the Acid2 test: http://weblog.timaltman.com/node/832

boo hoo!
(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)
(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.
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.
Depends on: 328241
It appears that this has been fixed on the reflow branch:
http://diary.e-gandalf.net/2006/04/12/meet-mr-face/
when will reflow branch get on trunk
*** Bug 341228 has been marked as a duplicate of this bug. ***
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.
Link died, here is the new one: http://fireflow.zendurl.com
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.
Depends on: b-order
Filed bug 343583 on the nose issue.
(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?
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.
(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.
(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 :)
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [wanted-1.9]
Whiteboard: [wanted-1.9] → [wanted-1.9][reflow-refactor]
No longer depends on: b-order
Is it normal that Firefox2 RC3's rendering has nothing to do with the reference image?
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.
(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.
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).
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
I know, just these builds are a bit different, mainly in that they have a modified installer that doesn't overwrite trunk installations.
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.
> 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.)
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.
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.
Last bugs fixed on trunk by reflow branch landing.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Verified with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/2006120804 Minefield/3.0a1

Whoa! :)
Status: RESOLVED → VERIFIED
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.
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...
(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?
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?
Depends on: 363246
(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.
(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/
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)
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).
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.
(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
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?
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.
The regression was bug 365191.  It's already fixed.
Depends on: 365191
Attached image 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
I see the same on FTP build from ftp.mozilla.org.
WFM, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/2007010204 Minefield/3.0a2pre
Depends on: 365809
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
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.
(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.

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.
New testcase which works in standalone HTML, you don't need webserver:

https://bugzilla.mozilla.org/attachment.cgi?id=254716&action=edit
Will there be an Acid3 test?
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.
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.
Why file a new bug? Why not just reopen bug 289480 and allocate the appropriate status?
This has always been a metabug, tracking the actual bugs that affect acid 2 rendering.
(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.
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*?
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.
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. 
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?
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?
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.)
(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.
Depends on: 377928
Filed Bug 377928 with a blocker to Bug 289480.
Reopening to make people happy.
Status: VERIFIED → REOPENED
Depends on: b-order, 361523
Resolution: FIXED → ---
Assignee: dbaron → chofmann
Status: REOPENED → NEW
QA Contact: ian → chofmann
(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.
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.
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 :)
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.
Depends on: 377928
No longer depends on: 377928
Depends on: 389561
Zoom out causes an orange bar to appear around the guy's eyes.
Shouldn't be Bug 352937 marked as blocker to this bug?
(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
Reflow-type operations like zoom do not count for acid2.
Depends on: 398763
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.
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
The site broke. I'm reporting it. Let me know if the Acid2 test still doesn't pass after the new year.
(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
(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.
Hixie's the person who wrote the test ;-)
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.
Yes, that's the error.

The test is also hosted on my site:
   http://www.hixie.ch/tests/evil/acid/002/
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.
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.)
Depends on: 409293
Attached patch ReftestSplinter Review
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.)
Depends on: 409329
(In reply to comment #179)
> The hixie.ch verson passes

http://img120.imageshack.us/img120/4421/ff3acid2ob8.png
Seems webstandards.org test is fixed now, both FX3.0b3pre and Opera 9.5b pass it again.
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.)
(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
Depends on: 400813
Depends on: 409717
Depends on: 409825
(In reply to comment #183)
> Seems webstandards.org test is fixed now, both FX3.0b3pre and Opera 9.5b pass
> it again.
> 

Confirmed
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
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.
(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.
Summary: Mozilla doesn't pass the acid2 (acid 2) test → Tracking bug for acid2 (acid 2) test
Flags: wanted1.9+
Whiteboard: [wanted-1.9][reflow-refactor] → [reflow-refactor]
Depends on: 415446
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.
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.
(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.
(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)"

(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]
(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.
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
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
> 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.
Depends on: 426616
Depends on: 426027
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.
(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/
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.
Blocks: 578114
Blocks: 579548
No longer depends on: 426027
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
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
I'm using 26.0 on Linux and the Acid2 is indeed broken. Acid3 is still fine.
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?
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
(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.
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.
Depends on: 965966
ACID2 is no longer rendering correctly in firefox, chrome or edge. 
There is red hatching across the eyes.
http://postimg.org/image/e185uc2vx/
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.
Component: Tracking → Layout
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
I think this bug can be closed, the live version seems OK. Zooming wasn't part of the original requirements (nice to have, should I open another bug? ;) )
https://www.webstandards.org/files/acid2/test.html
-- Bart
Flags: needinfo?(svoisen)
Flags: needinfo?(svoisen)
Yeah, closing.
Status: NEW → RESOLVED
Closed: 18 years ago5 years ago
Resolution: --- → FIXED
Summary: Tracking bug for acid2 (acid 2) test → [meta] Tracking bug for acid2 (acid 2) test
Restrict Comments: true
You need to log in before you can comment on or make changes to this bug.