Nicolás Lichtmaier Reporter
	Description • 18 years ago

Adding padding to a label makes clicking them to give focus to the wrong component. It's as if the calculation of which thing has ben hit by the click is different than the actual layout algorithm. Perhaps the wrong thing is layout, as I see no padding in the result. I'm using Firefox 2.

	Ria Klaassen (not reading all bugmail)
	Comment 2 • 18 years ago

I see only a I-beam cursor when I click under C if this is what you mean.
Which is a regression between 1.9a1_2006012517 and 1.9a1_2006012609.

	Steve England [:stevee]
	Comment 3 • 18 years ago

When I click 'A' the cursor appears in text area B, and when I click 'B' the cursor appears in text area C. Is this what you mean Nicolás?

	Ria Klaassen (not reading all bugmail)
	Comment 4 • 18 years ago

When I click in the middle of every input field, there is no problem.
Only when I try to focus the first half cm of fields A and B. My "remove elements" bookmarklet shows that the beginning of field B is covered by the label of C and the label of B covers the first half cm of field A.

	Ria Klaassen (not reading all bugmail)
	Comment 5 • 18 years ago

Regression range of comment #2:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-01-25+16%3A00&maxdate=2006-01-26+10%3A00
Caused by Bug 317375 ?

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 6 • 18 years ago

Probably

	Nicolás Lichtmaier Reporter
	Comment 7 • 18 years ago

The problem I see is that when you click on the labels, the wrong controls gets the focus. And the "offset" can be modified by adjusting the padding.

	Boris Zbarsky [:bzbarsky]
	Comment 8 • 18 years ago

So... the thing is that the padding of the "B" label overlaps the A label.  You can see this if you give the three labels borders of three different colors or given them a background color.  Since the B label is painted after the A label, clicking on the overlap triggers the B label.

So either we shouldn't be considering the padding area when doing hit testing, or we had a bug before we fixed bug 317375.  I suspect the former (which would make this bug invalid).

Note also bug 102695.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 9 • 18 years ago

Did you mean "the latter" when you said "the former"?

This bug is invalid either way anyway, right? Either we need to make padding transparent to events, which is a different bug, or we should do nothing.

	Boris Zbarsky [:bzbarsky]
	Comment 10 • 18 years ago

Er, I meant "the latter".

And if you agree, then it is so.  ;)

	Nicolás Lichtmaier Reporter
	Comment 11 • 18 years ago

Hi, I'm the reporter =). Perhaps I'm missing something... but why is there no padding there? Isn't that a bug?

	Boris Zbarsky [:bzbarsky]
	Comment 12 • 18 years ago

There is padding.  It's just that vertical padding and borders don't affect line heights.  See the CSS2.1 specification.