Open
Bug 427088
Opened 17 years ago
Updated 2 years ago
Links in second column of page aren't clickable
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Core
DOM: UI Events & Focus Handling
Tracking
()
NEW
People
(Reporter: svgunhouse, Unassigned)
References
(Depends on 1 open bug, )
Details
(Keywords: regression, testcase)
Attachments
(2 files)
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 ...
Updated•17 years ago
|
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
Comment 1•17 years ago
|
||
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...
Comment 2•17 years ago
|
||
Here's a simpler testcase to illustrate the bug, "link2" works,
the other links don't work.
Updated•17 years ago
|
Something like this might trigger bug 570309.
But anyway, this is serious enough, request blocking.
blocking1.9.2: --- → ?
Keywords: regression
Comment 4•15 years ago
|
||
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: ? → -
status1.9.2:
--- → wanted
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.
![]() |
||
Comment 6•15 years ago
|
||
"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....
Comment 7•15 years ago
|
||
> 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.
Comment 8•9 years ago
|
||
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)
Comment 9•9 years ago
|
||
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)
Assignee | ||
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
Updated•2 years ago
|
Severity: minor → S4
You need to log in
before you can comment on or make changes to this bug.
Description
•