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

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.

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

Made the same mistake as in comments 7/8, d'oh.

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

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

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

The table issue was discussed in: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0025.html http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0026.html http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0027.html ...and I maintain that the test is correct.

Please share. Those are members only posts.

As I'm sure Hixie knows, he's posted some test cases: http://www.hixie.ch/tests/evil/acid/002/opera001.html http://www.hixie.ch/tests/evil/acid/002/opera002.html http://www.hixie.ch/tests/evil/acid/002/opera003.html http://www.hixie.ch/tests/evil/acid/002/opera004.html http://www.hixie.ch/tests/evil/acid/002/opera005.html http://www.hixie.ch/tests/evil/acid/002/opera006.html http://www.hixie.ch/tests/evil/acid/002/opera007.html http://www.hixie.ch/tests/evil/acid/002/opera008.html http://www.hixie.ch/tests/evil/acid/002/opera009.html http://www.hixie.ch/tests/evil/acid/002/opera010.html http://www.hixie.ch/tests/evil/acid/002/opera011.html Don't know how much they help ... but thought they might be worth linking to. Not sure which applies to which row of the test off hand.

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

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

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

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.

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

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)

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 ;)

See comment 12, first bullet point.

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.

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.

Shows the progress made after bug 317375 (frame display lists) landed.

(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

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.

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.

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 :)

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

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

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.

Verified with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/2006120804 Minefield/3.0a1 Whoa! :)

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?

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

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

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.

The nose is not misrendered. See bug 343583 comment 6.

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.

Filed Bug 377928 with a blocker to Bug 289480.

Reopening to make people happy.

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

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.

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

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

(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

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

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.

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.

Bruno see http://whereswalden.com/2009/02/20/when-good-tests-go-bad-firefox-on-acid2/

(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/