Closed
Bug 383536
Opened 17 years ago
Closed 16 years ago
Clicking on links on higher layers do not work the first time
Categories
(Camino Graveyard :: General, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 365987
People
(Reporter: j, Unassigned)
References
()
Details
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.4) Gecko/20070509 Camino/1.5 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.4) Gecko/20070509 Camino/1.5 In some cases, clicking a link doesn't work the first time. You need to click on the same link for the second time to make it work. Reproducible: Always Steps to Reproduce: 1. Go to www.google.com. 2. Click on "more" on the top bar. A drop down menu will appear. 3. Click on anything you want. It will NOT work. 4. Click again. It will work the second time. Actual Results: The link did not open. Expected Results: Link should have opened.
Summary: Click on menus do not work the first time → Clicking on links on higher layers do not work the first time
Comment 1•17 years ago
|
||
That's really weird. I can definitely reproduce this most of the time (spoofed or not), and it seems to be fine in Firefox. It appears to be treating the click as a short drag, rather than a click. I wonder if this is related to the problems we have with Yahoo mail's beta.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•17 years ago
|
||
Even weirder: this works fine in Camino 2007060505, at least for me.
I just downloaded Camino 2007060605 and I still have the same problem. It appears to happen only when there is a background hover. For example, go to http://books.google.com/ and click on the "more" link there. It works without any problems.. Here is another weird behaviour that could give you guys an idea of what is going on wrong: 1. Login to calendar.google.com. 2. On the left hand side, you will see an "Add" button in the box that lists the calendars. 3. Click on the Add button and choose anything you want. For some reason, it acts as if the mouse click was NOT released. You will notice the text on page will be highlighted as you move your mouse. Also, you can also generate the orginal click bug I've reported by clicking on the arrows next to the calendar names and selecting anything. I hope this helps..
I see link-clicks getting "stuck" all the time on all sorts of sites; I just assumed it was some Gecko bug, or something like bug 168725.
Comment 5•17 years ago
|
||
Ah, the reason I was seeing an issue with the Google menu only some of the time is that if you click on the text it's broken, but if you click on the non-text area of an item it works fine.
Comment 6•17 years ago
|
||
Other notes from poking at this: 1) The menu is built *over* an iframe (to provide a background, I guess); everything works if I use a div instead, or just make the iframe 0-height. 2) The links actually become active when clicked, even though they don't work 3) It works fine in trunk Given 1, I'm suspecting that this may be another instance of bug 365987, but I'll keep messing with it.
Comment 7•17 years ago
|
||
My experience with this bug coincides with "Awesome"'s. My site contains a link that's on a higher div layer that also has a onmouseover event, and that's precisely where the bug occurs. The site is www.coventi.com, a document collaboration site that allows in-context, threaded conversations (you must create an account to use it). The bug occurs when you click the "create comment" link in the pop-up div that appears after you've just highlighted a section of text for discussion.
Comment 8•17 years ago
|
||
Definitely confined to branch per comment 6 and my comment 2 (I forgot to specify, but that was with a trunk build).
Version: unspecified → 1.8 Branch
Comment 9•17 years ago
|
||
Searching back in trunk, it appears this started working in: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=Camino&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-10-24+23%3A00%3A00&maxdate=2006-10-25+18%3A00%3A00&cvsroot=%2Fcvsroot which suggests that it was the drag-and-drop rewrite (which given the appearance of being dragged and released I mentioned in comment 1 I would believe). Unfortunately that patch doesn't even remotely apply, so I'm not sure we can realistically backport enough to make it work if it is indeed a dnd-related bug.
Comment 10•17 years ago
|
||
Stuart, did you ever decide if this was related to bug 365987 or not?
Comment 11•16 years ago
|
||
I'm pretty sure that this is bug 365987, so duping.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•