Weird interaction between padding and form labels.

RESOLVED INVALID

Status

()

defect
RESOLVED INVALID
13 years ago
12 years ago

People

(Reporter: nick, Unassigned)

Tracking

({regression})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

13 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.
Reporter

Comment 1

13 years ago
Posted file testcase
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.
Keywords: regression
OS: Linux → All
Hardware: PC → All
Version: 1.8 Branch → Trunk
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?
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.
Reporter

Comment 7

13 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.
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.
Blocks: 317375
Flags: blocking1.9?
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.
Er, I meant "the latter".

And if you agree, then it is so.  ;)
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
Reporter

Comment 11

13 years ago
Hi, I'm the reporter =). Perhaps I'm missing something... but why is there no padding there? Isn't that a bug?
There is padding.  It's just that vertical padding and borders don't affect line heights.  See the CSS2.1 specification.
Flags: blocking1.9?
You need to log in before you can comment on or make changes to this bug.