Links in second column of page aren't clickable

NEW
Unassigned

Status

()

defect
--
minor
12 years ago
4 months ago

People

(Reporter: svgunhouse, Unassigned)

Tracking

(Depends on 1 bug, {regression, testcase})

unspecified
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking1.9.2 -, status1.9.2 wanted)

Details

()

Attachments

(2 attachments)

User-Agent:       Opera/9.50 (X11; Linux i686; U; en)
Build Identifier: Firefob 3b3 and later

Go to http://portal.opera.com and if not previously configured then add one or more news sources to be displayed. The titles for the articles in the second column are aligned wrong and are not clickable in 3b5 (or any version since 3b3).

The page worked fine in 3b2, 2.0.x, Opera and Safari

Reproducible: Always

Steps to Reproduce:
1. Go to http://portal.opera.com
2. Add one or more news sources to be displayed
3. look at the right hand column
Actual Results:  
The title of the article appears the line below the source's icon (behind the icon for next article), and except for the last article the links are not clickable.

Expected Results:  
The title appears next to the source's icon, and clicking the title loads the article.

I gather your people don't normally look at Opera's version of a start page. This has been bothering me since 3b3 came out, but I figured someone else would find it and you'd have fixed it by now. But here it's 2 betas later and still broken ...
Severity: major → minor
Status: UNCONFIRMED → NEW
Component: General → Event Handling
Ever confirmed: true
OS: Linux → All
Product: Firefox → Core
QA Contact: general → events
Hardware: PC → All
Posted file Testcase #1
This testcase is a simplified version of http://portal.opera.com/

The <a> links in the right column are blocks with hardcoded width:246px,
the container <li class="even"> have max-width:46% which is equivalent to
max-width:264.96px since its container <ul> has width:576px.
The <li class="even"> have two child blocks, the first is a float:left
<span> with width:20px and the second is the <a> link (width:246px).
20px + 246px > 264.96px so the link does not fit next to the float and
is pushed to the next line. Since the container <li> has a hardcoded
height:20px the link is now outside its container and *under* the
next <li> float.
Clicking in this area apparently does not find the overflowed link...
Posted file Testcase #2
Here's a simpler testcase to illustrate the bug, "link2" works,
the other links don't work.
Depends on: 102695
Keywords: testcase
Blocks: 570309
Something like this might trigger bug 570309.
But anyway, this is serious enough, request blocking.
blocking1.9.2: --- → ?
Keywords: regression
Not blocking a 1.9.2 security update, but if we get a trunk patch because of 570309 we can talk about approving the patch.
blocking1.9.2: ? → -
oops, my intention was to ask for 1.9.3 blocking.
I'll file a new bug with the exact testcase of bug 570309 and request there.
Blocks: 570647
"testcase #2" works identically in current Gecko, current Webkit, and Firefox 2, and the behavior there seems correct to me as long as we're not making transparent areas transparent to events.  So the regression is just being moved down a row in "testcase #1", right?  But on that testcase, we have the same rendering as current webkit and as Opera (except the link is clickable in Opera for some reason but NOT in webkit).

So offhand, this looks invalid to me....
> seems correct to me as long as we're not making transparent areas
> transparent to events

Agreed, I probably left this open but dependent on bug 102695
since it's an edge case...

> [testcase #1] ... we have the same rendering as current webkit and as Opera

Yes, the layout of testcase #1 is correct.  

> except the link is clickable in Opera

Yeah, Opera propagates clicks through [some] transparent elements -
all the links in testcase #2 are clickable, but if I add background:pink
to the blocks that cover the links then link1 and link4 are not clickable.
(link3 (opacity) is still visible and clickable, but their layout here
seems wrong)

This bug is the same underlying issue as bug 102695 but has some
interesting edge cases to consider if we decide to implement 102695.
If we wontfix 102695, then this bug should be duped/wontfix as well.
Is this issue still relevant or is it invalid? We are updating all old bugs with the "testcase" flag set.
Flags: needinfo?(mats)
Flags: needinfo?(bzbarsky)
This bug should stay open until we make a decision about bug 102695.
(this probably goes for all bugs referenced by bug 102695)
Flags: needinfo?(mats)
Flags: needinfo?(bzbarsky)
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.