User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050531 Camino/0.8+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050531 Camino/0.8+ This happens once I have too many tabs/windows open in Camino. The program starts responding slower, but still operates. In general, it works fine any other time. Reproducible: Didn't try Steps to Reproduce: 1. Open a couple of windows/tabs quickly. 2. Try clicking on links quickly. Actual Results: The mouse pointer did not convert to a hand after I put it over a link. The links still works when I click on them. Expected Results: Pointer should convert to a hand and the pages should move smoothly.
can you get a better case to reproduce here?
Reporter, does thsi problem still occur in 0.9a1 or a recent nightly build? If so, can you provide a better testcase as requested in comment 1; otherwise, we will have to close this bug.
I can't seem to reproduce it consistently. It has something to do with having flash or a strange div in another tab. It happens sometimes if I am at flickr (flickr.com) and I have it open in two or more tabs. I have a flash program running on their site and then I edit a photo elsewhere and then... it suddenly doesn't turn to a pointer. I can still click a link, but it doesn't do any rollover effects, etc. I'll try to reproduce it some more, but it's very ocassional it seems. I'm sorry.
I just saw this, too. Camino 2005081604 (v0.9a2+) 1.8 branch, 10.3.9. You don't get tooltips for titles when hovering over bug numbers in bugzilla and :hover doesn't seem to work on pages that use it, either. It seemed to suddenly appear after I had been scrolling one of those large bugs that takes a long time to load while it was loading, and then it finished loading and reloaded (need to be on a slow connection to see the bugzilla behavior), bug 258285. I'm not sure that's really the cause, though, because I scroll-while-loading on bug 197813 often and had never seen this before :-(
Whiteboard: need info
I see this ocassionaly too, mostly when my computer is busy.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This problem have shown up a lot more frequent latelly. I can easily reproduce like this: 1. Hide Camino (cmd+h) 2. Show Camino 3. Move the mouse-pointer to a link. It dont change to the "hand" pointer I wonder if the 297343 fix have cause this bug to appear more frequent?
*** Bug 311084 has been marked as a duplicate of this bug. ***
Summary: mouse pointer does not convert to hand when i put it over a link → After using Command-tab to reveal Camino, page focus is lost (no hand pointer over links)
Whiteboard: need info
Target Milestone: --- → Camino1.0
I got a reproducible test case for the "loss of hand cursor" cursor bug: - hide Camino - bring it back to the front (COMMAND+TAB or using the Dock) - (the hand cursor still appears) without clicking on any link, choose another tab - hand cursor is gone, even if you go back to the previous tab. It seems that the page content does not matter. The only work around it to activate another app without hiding Camino then go back to Camino. Cheers.
It s(In reply to comment #8) > I got a reproducible test case for the "loss of hand cursor" cursor bug: > [...] It seems that it's Tiger only. Another user (Uncle Asad, reported in the Mozillazine Camino forum)) tested with the same 11-03 branch build on OS X 10.3.9 and had no problem. But it always happen with me with both 11-03 and 11-04 branh builds. Cheers
[Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051116 Camino/1.0b1+] I have alternate steps to reproduce: - go to a page with links (this page on Bugzilla will do) - hide Camino - show Camino At this point, when you hover over links, the cursor will change to a hand, as it should, but if you - click anywhere in Camino that isn't a link, the menu bar, or the scroll bar (a blank area of the page, the location bar, bookmarks bar, tab bar all "work") when you hover over links now, the cursor won't change. I can get the hand to come back by bringing up the context menu, if that helps.
I had always wondered how to trigger this bug. I see it as well, and can confirm frank's method of triggering it. 12/5 trunk, 10.4.3.
This is evil for most users. Requesting blocking.
do we know when this regressed?
Flags: camino1.0? → camino1.0+
(In reply to comment #13) > do we know when this regressed? The steps to repro started 30 Sept 2005 on trunk and 06 Oct 2005 on branch.
Looks like the fix to Bug 297343 caused this.
Bug 297343 was fixed for the 9/30 build and this bug didn't exist in that build (at least I can't reproduce in that build). There were no builds for 3 days, then it appeared in the next nightly build: 10/04. I tested on the trunk nightlies.
Actually, the cursor won't change to the hand cursor after the first click. For instance, after Camino is unhide, the hand cursor still appears, but it won't anymore after a link is clicked (selected). Also, you will still be able to click on links (it does work) after that but the cursor won't change to the hand one anymore. And as I said before, it seems that it's a 10.4 only issues.
I can confirm Frank's method, and the bug, on 10.4.4 here.
This bug really morphed along the way, unfortunately. As it stands, this report now covers the issue in comment 6 onward, a 10.4-only issue.
Summary: After using Command-tab to reveal Camino, page focus is lost (no hand pointer over links) → [10.4] After using Command-tab to reveal Camino, page focus is lost (no hand pointer over links)
Is this still slated to block 1.0 or has that been removed to expediate the release?
(In reply to comment #20) > Is this still slated to block 1.0 or has that been removed to expediate the > release? > Since this is a non-trivial bug to fix, there's a good chance it won't make 1.0.
This seems to be an AppKit issue. When focus is "lost", we're not getting any mouse moved events, even though the window is frontmost. But if you are in this state and you just click on the titlebar of the window, we start getting mouse moved events again. Weird.
(In reply to comment #22) > ...and you just click on the titlebar of the window Actually just mouse over the url bar which calls -setAcceptsMouseMovedEvents:YES) on the window). This suggests a workaround.
Created attachment 210058 [details] [diff] [review] Patch: call setAcceptsMouseMovedEvents:YES every time the window becomes main
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Keywords: fixed220.127.116.11, fixed1.8.1
Resolution: --- → FIXED
Yup, it looks like it's fixed. Awesome. (Verfied using my steps from above and today's build from the latest-1.0 folder.)
You need to log in before you can comment on or make changes to this bug.