User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090131 Minefield/3.2a1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090131 Minefield/3.2a1pre Minefield thinks that the button should start from the left side of the screen, and all the way to where the button really is. This makes the Footprint, CSS3 Compliant and Cross-browser links inaccessible. Reproducible: Always Steps to Reproduce: 1. Go to http://jquery.com/ 2. Click on Lightweight Footprint, CSS3 Compliant or Cross-browser. Actual Results: It takes me to http://code.google.com/p/jqueryjs/downloads/detail?name=jquery-1.3.1.min.js&downloadBtn= Expected Results: It should take me to http://docs.jquery.com/Tutorials Removing position: relative from the button seems to solve the problem. It's not a problem in Firefox 3.0.5

regressed: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090127 Minefield/3.2a1pre http://hg.mozilla.org/mozilla-central/rev/4a34b7ff26e2 fails Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090128 Minefield/3.2a1pre http://hg.mozilla.org/mozilla-central/rev/42b8e2c66c5b http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4a34b7ff26e2&tochange=42b8e2c66c5b possibly: Bug 475197 ? The button is positioned relative and contains an absolute positioned span with 'left: -9999999px;'. according to DomI, Minefield sees this as 'left:-1e+7px;'

The link should be clickable. (The testcase doesn't show the weird value for left)

Did you confirm this through backout? Unless the button uses box-shadow I heavily doubt the suspected bug is the culprit.

(In reply to comment #3) > Did you confirm this through backout? Unless the button uses box-shadow I > heavily doubt the suspected bug is the culprit. No, apparently my local three is hooosed. Sorry about that. But I don't really see anything else in that list in comment 1 that would cause this. I'd love to be proven wrong, though. BTW, 1. the latest Shiretoko (20090131, OSX) build is not affected. 2. it is really limited to <button>. I tried to reproduce the issue with a <span> inside a block element (<p>, set to block or inline-block), but that works correctly.

It can't be... if it is, it's a bug in the display list.

Looks like a regression from bug 475197 to me. In particular, this part in nsButtonFrameRenderer: +nsRect nsDisplayButtonBorderBackground::GetBounds(nsDisplayListBuilder* aBuilder) +{ + return mFrame->GetOverflowRect() + aBuilder->ToReferenceFrame(mFrame); +} In this case, the overflow rect covers everything to the left of the button due to the positioned span, right? The button borderbackground goes on top of the dispay list, not in the background layer (see nsButtonFrameRenderer::DisplayButton). So that change causes all event delivery to anywhere in the overflow area to go to the button. That's wrong, no?

Yeah, that was a mistake. We need to use a separate display item for the shadow, one that doesn't catch events.

Use a new display list item instead of changing the existing one.

BTW can you write a mochitest to check that box-shadows for various elements don't capture mouse clicks? Should be easy using elementFromPoint.

Pushed http://hg.mozilla.org/mozilla-central/rev/3113b31e4086

The patch doesn't seem to apply on branch.

Alright, bug 475197 hasn't landed yet on branch...

Verified on trunk with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090208 Minefield/3.2a1pre ID:20090208020444 and the identical build on Windows.

(In reply to comment #13) > Alright, bug 475197 hasn't landed yet on branch... In which order should these two bugs be checked in ?

475197 has landed on branch now. This should be landed ASAP.

Pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a89c15ae069e

Verified with on 1.9.1 with builds on OS X and Windows: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090227 Shiretoko/3.1b3pre ID:20090227020413