476308 - "Download jQuery" button is clickable from the left side of the screen to the button

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P2)

Description

[Anders G. Jørgensen]

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

Comment 1

[philippe (part-time)]

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

Comment 2

[philippe (part-time)]

Attachment: test case

The link should be clickable.

(The testcase doesn't show the weird value for left)

Comment 3

[Michael Ventnor]

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

Comment 4

[philippe (part-time)]

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

Comment 5

[Michael Ventnor]

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

Comment 6

[Boris Zbarsky [:bzbarsky]]

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?

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 8

[Michael Ventnor]

Attachment: Patch

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

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 10

[Michael Ventnor]

Attachment: Mochitest

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 12

[Dão Gottwald [:dao]]

The patch doesn't seem to apply on branch.

Comment 13

[Dão Gottwald [:dao]]

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

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 15

[Serge Gautherie (:sgautherie)]

(In reply to comment #13)
> Alright, bug 475197 hasn't landed yet on branch...

In which order should these two bugs be checked in ?

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 17

[Boris Zbarsky [:bzbarsky]]

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

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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