Weird interaction between padding and form labels.

RESOLVED INVALID

Status

()

Core
Layout: Form Controls
RESOLVED INVALID
12 years ago
11 years ago

People

(Reporter: Nicolás Lichtmaier, Unassigned)

Tracking

({regression})

Trunk
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 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

12 years ago
Created attachment 246749 [details]
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

12 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
Last Resolved: 11 years ago
Resolution: --- → INVALID
(Reporter)

Comment 11

11 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.
You need to log in before you can comment on or make changes to this bug.