Last Comment Bug 351491 - first click in a window does not follow a link with caret browsing on
: first click in a window does not follow a link with caret browsing on
Status: RESOLVED FIXED
: access, fixed1.8.1.1, regression, sec508
Product: Core
Classification: Components
Component: Keyboard: Navigation (show other bugs)
: Trunk
: x86 All
-- normal with 5 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors:
: 348528 353005 354619 355962 357617 358409 359424 360412 360956 361504 361860 363213 363357 (view as bug list)
Depends on:
Blocks: 144000
  Show dependency treegraph
 
Reported: 2006-09-05 16:54 PDT by James Rome
Modified: 2006-12-17 23:52 PST (History)
28 users (show)
dveditz: blocking1.8.1.1+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
prefs.js zipped (38.88 KB, application/x-zip-compressed)
2006-09-25 08:35 PDT, James Rome
no flags Details

Description User image James Rome 2006-09-05 16:54:21 PDT
This happens on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060821 SeaMonkey/1.1a and on earlier builds. And in both the mail and browser windows.
for example, if I read an e-mail by clicking it in the mail list, and see a link in the mail message, clicking it brings me to the top of the message instead of following the link. If I click in the message body first, the link works.
Similarly, if you read Javadaocs (http://java.sun.com/j2se/1.5.0/docs/api/index.html) 
sometimes the same thing happens. It happened this afternoon, but not when I just tried it again.
Comment 1 User image James Rome 2006-09-24 12:05:42 PDT
This is becoming increasingly annoying. I must click in every window before clicking a link. Otherwise, I am sent back to the top of the window.
Comment 2 User image Andrew Schultz 2006-09-24 19:23:46 PDT
Do you know when this started happening?  Do you see this with a clean profile?  Do you have any extensions installed?
Comment 3 User image James Rome 2006-09-25 06:43:28 PDT
This has been happening with me since I have tried 1.1 -- a long time. I have NoScript, Enigmail, dBlockerPro, ExtensionManager, FlashBlock, Web Developer, and PasswordMaker installed. It does not do this on 1.0.5 on my laptop.

I did not try it with a clean profile. Until Mozilla gives us a way to import saved passwords and certificates from one profile to another, this gets very difficult.
Comment 4 User image Andrew Schultz 2006-09-25 08:11:59 PDT
> I did not try it with a clean profile. Until Mozilla gives us a way to import
> saved passwords and certificates from one profile to another, this gets very
> difficult.

I'm not suggesting you switch to a clean profile.  Just test this bug with a clean profile.  Unless this happens sufficiently rarely that you can't just test it.
Comment 5 User image James Rome 2006-09-25 08:35:58 PDT
Created attachment 240017 [details]
prefs.js zipped

My prefs.js file
Comment 6 User image James Rome 2006-09-25 08:36:18 PDT
A clean profile definitely does not show this problem. I installed most, but not all of the extensions too. I attach my prefs.js file.
What could cause this?
Comment 7 User image Andrew Schultz 2006-09-25 19:07:57 PDT
Using your prefs.js does not cause the bug for me.

If you remove your prefs.js from your profile, does the bug go away?  If so, Try deleting parts of your prefs.js until the bug goes away.  It might be some combination of prefs and an extension.
Comment 8 User image Andrew Schultz 2006-09-25 19:14:58 PDT
actually, I lied.  Your prefs.js file didn't actually make it into my profile directory.

It looks like you're suffering from bug 194937.  Try hitting F7.
Comment 9 User image James Rome 2006-09-25 19:28:41 PDT
Definitely not the caret browsing bug. The keys work fine for me. I had never heard of caret browsing before. My bug is a mouse only issue. It seems as if the focus is not changed to the clicked pane the first time it is clicked.

I'll play with prefs.js.
Comment 10 User image James Rome 2006-09-25 19:39:36 PDT
This is bizarre. I dragged prefs.js to my desktop and restarted seamonkey. I had no bookmarks or e-mail accounts when it came up. But, for the first time the Web Developer tool bar appeared. I stopped Mozilla and dragged prefs.js back to my folder. Now the Web Developer bar still appears and the symptoms seem to be gone. But I did not change prefs.js at all.

I'll see if it stays fixed.
Comment 11 User image Andrew Schultz 2006-09-25 21:47:14 PDT
I'd guess that caret browsing isn't supposed to affect mouse and certainly shouldn't cause what you're seeing, but caret browsing has bugs.

Anyway, I see what you describe with caret browsing on (and it's enabled in the prefs.js you attached, "accessibility.browsewithcaret") and I don't see it once I turn it off.  If you're not seeing it anymore, make sure you haven't disabled caret browsing.  When you enable it, you should get a dialog.  When you disable it, there's no dialog.
Comment 12 User image James Rome 2006-09-26 06:53:06 PDT
I have disabled caret browsing. Seems like this should be the default. So far so good.
Comment 13 User image James Rome 2006-09-26 06:56:57 PDT
If the mouse gets screwed up with caret browsing on, then I think this is a legitimate bug that needs to be fixed.
Comment 14 User image Andrew Schultz 2006-09-26 07:58:04 PDT
OK.  This is a regression from bug 144000.  Might be a dupe of bug 334637
Comment 15 User image Ginn Chen 2006-09-26 22:20:06 PDT
I have met something like this before.
It just happens occasionally, I couldn't reproduce it every time.

Maybe we should move the hunk in Bug 14400 to somewhere else.
Or deal with mouse click setting focus.
Comment 16 User image Ginn Chen 2006-09-26 22:43:44 PDT
I still have no idea how bug 14400 caused this.
One possible reason, middle-click or right-click sets focus to links without calling nsEventStateManager::SetContentCaretVisible
Comment 17 User image Ginn Chen 2006-10-23 02:24:25 PDT
Bug 357617 gives a testcase for this.

I debugged into it and found
nsEventStateManager::SetContentCaretVisible was called twice for the click.
first triggered by nsGlobalWindow::Focus, second by nsHTMLAnchorElement::PostHandleEvent

I guess CompleteMove shifts focus out of the link.
I think we should move the patch of bug 144000 to somewhere else.

If needed, we should back it out at this time.
Comment 18 User image Ginn Chen 2006-10-23 02:25:45 PDT
*** Bug 357617 has been marked as a duplicate of this bug. ***
Comment 19 User image Ginn Chen 2006-10-23 02:26:15 PDT
*** Bug 353005 has been marked as a duplicate of this bug. ***
Comment 20 User image Adam Guthrie 2006-10-23 10:57:17 PDT
*** Bug 348528 has been marked as a duplicate of this bug. ***
Comment 21 User image Ginn Chen 2006-10-24 05:15:34 PDT
I fount if the click is on the first page, i.e. CompleteMove doesn't cause a scroll,
this bug will not occur.

Maybe we should put the caret at the current scroll position instead of topmost.
Or maybe we may suppress the scroll.
Comment 22 User image :Gavin Sharp [email: gavin@gavinsharp.com] 2006-10-26 07:34:24 PDT
*** Bug 354619 has been marked as a duplicate of this bug. ***
Comment 23 User image :Gavin Sharp [email: gavin@gavinsharp.com] 2006-10-26 07:34:30 PDT
*** Bug 355962 has been marked as a duplicate of this bug. ***
Comment 24 User image W.Baron 2006-10-27 04:15:46 PDT
I get this bug first time yesterday with Firefox 2.0.
I assume it is a problem with frames and focuses.
An easy way to reproduce:
- go to http://java.sun.com/j2se/1.5.0/docs/api/index.html
- scroll all three frames to the bottom in this order:
  top left, bottom left, right;
- click the link "org.xml.sax.helpers" in the top left frame.
- the frame scrolls automatically to the top.
Comment 25 User image Martin Pelant 2006-10-27 04:21:35 PDT
Try to disable,  apply and enable options in Options->Advanced->General
This way I "killed" this bug :)
Comment 26 User image clc4tts 2006-10-27 11:46:58 PDT
Summary of my experiences with this bug so far:
1. Only happens on pages with frames.
2. Only happens when I scroll down on a frame that I have not clicked in previously and click on a link. On subsequent clicks, this bug does not appear.

What seems to be happening is that when I focus on a frame by clicking on it, then Firefox tries put in the navigation cursor and it ends up at the top of that frame, which is a bug since I actually clicked on a link somewhere near the bottom of the frame and expect the cursor to go there. However, if I focus on another frame and go back to a frame, the frame that I go back to is fine. So I think it only a problem if Firefox is initializing the navigation cursor for the frame.

This leads to the possibility of an ugly (but effective) workaround. Focus on the frame as soon as the user mouses over it. If you do this, then by the time the user has scrolled to the bottom of the frame, then the cursor will already have been initialized and there won't be this skipping problem.

I have tested this fix by adding it to a development build of my extension, and it seems to get around this problem quite well. I have not missed a click since using it. :)

function CLC_CS_FFCursorFix_FocusOnMouseover(event){
   event.target.contentWindow.focus();
   }

//Call this function on load
function CLC_CS_FFCursorFix(){
   var framesArray = window._content.document.documentElement.getElementsByTagName("frame"); 
   for(i =0; i < framesArray.length; i++){
      framesArray[i].addEventListener("mouseover", CLC_CS_FFCursorFix_FocusOnMouseover, false);
      }
   }

Comment 27 User image clc4tts 2006-10-27 11:49:58 PDT
In response to Martin Pelant (or rather, to help clarify what he said):

The option that causes this is:
"Always use the cursor keys to navigate within pages" 

This bug doesn't happen if that is unchecked since the bug is caused by caret navigation being started inside a frame.
Comment 28 User image clc4tts 2006-11-02 16:16:21 PST
Actually, there is a much smarter hack...

function CLC_CS_FFCursorFix(){
   var framesArray = window._content.document.documentElement.getElementsByTagName("frame"); 
   for(i =0; i < framesArray.length; i++){
      framesArray[i].contentWindow.focus();
      }
   }

The handler isn't even needed... just cycle the focus through all frames and voila, problem solved.
Comment 29 User image Ginn Chen 2006-11-06 19:50:22 PST
Fixed by backing out bug 144000
Comment 30 User image Ginn Chen 2006-11-07 21:15:32 PST
nominate blocking 1.8.1.1
the solution now is to back out the patch of bug 144000.
Comment 31 User image Ria Klaassen (not reading all bugmail) 2006-11-16 13:58:17 PST
*** Bug 360956 has been marked as a duplicate of this bug. ***
Comment 32 User image :Gavin Sharp [email: gavin@gavinsharp.com] 2006-11-19 11:44:23 PST
*** Bug 359424 has been marked as a duplicate of this bug. ***
Comment 33 User image :Gavin Sharp [email: gavin@gavinsharp.com] 2006-11-19 11:47:18 PST
*** Bug 360412 has been marked as a duplicate of this bug. ***
Comment 34 User image :Gavin Sharp [email: gavin@gavinsharp.com] 2006-11-20 12:24:34 PST
*** Bug 358409 has been marked as a duplicate of this bug. ***
Comment 35 User image Martijn Wargers [:mwargers] 2006-11-22 04:58:58 PST
*** Bug 361504 has been marked as a duplicate of this bug. ***
Comment 36 User image Sergey Koulik 2006-11-22 18:15:07 PST
Hello all,

Please excuse me for silly question,
but where could I download 1.8.1.1 from?
Comment 37 User image Tony Mechelynck [:tonymec]. (NEEDINFO me if you want my attention) 2006-11-22 18:30:34 PST
(In reply to comment #36)
> Hello all,
> 
> Please excuse me for silly question,
> but where could I download 1.8.1.1 from?
> 

Starting Nov.22, some builds branded "rv=1.8.1.1pre" are available, for instance
"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1pre) Gecko/20061122 BonEcho/2.0.0.1pre" (Build ID: 2006112204), a Firefox build which I got from
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8.1
Warning: "Nightly" builds only.
Comment 38 User image Ria Klaassen (not reading all bugmail) 2006-11-26 00:43:48 PST
*** Bug 361860 has been marked as a duplicate of this bug. ***
Comment 39 User image Ulrich Windl 2006-11-30 03:47:38 PST
IMHO this bug is so ugly that it does justify releasing Firefox 2.0.1 ASAP. I'm really considering to go back to 1.5, because usability in 2.0 is so annoying (regarding this issue).
Comment 40 User image F. Nold 2006-12-01 05:54:59 PST
(In reply to comment #39)
> IMHO this bug is so ugly that it does justify releasing Firefox 2.0.1 ASAP. I'm
> really considering to go back to 1.5, because usability in 2.0 is so annoying
> (regarding this issue).

I strongly agree about everything written above! Imagine a normal user clicking on a submit button on the bottom of a page: Firefox will jump to top of page and the user believes his data has been send... Patched 2.0.1 for this Issue should be released immediately IMHO

Comment 41 User image tjhacker87 2006-12-01 09:26:52 PST
You can fix the problem yourself by disabling the 'Always use the cursor keys to navigate' option and the 'Use autoscrolling' option.  Works just fine for me now.
Comment 42 User image Boris 2006-12-02 18:32:33 PST
More examples of problems that still/also exist: does not scroll to the bottom when press Ctrl+End at http://persistent.info/ and jumps back to top when backing from the page after a bookmarklet is click at http://www.squarefree.com/bookmarklets/search.html?&num=100.

This problem costs users a long time to debug; worse, it is not solved after disabling all extensions. Disabling the caret option not known to everybody and some people do need the option on, so the bug has not been really fixed.

Any idea on when the next update will be released? We cannot just "Leave as RESOLVED FIXED" like now.
Comment 43 User image Cameron 2006-12-02 19:46:18 PST
(In reply to comment #42)
> Any idea on when the next update will be released? We cannot just "Leave as
> RESOLVED FIXED" like now.
> 
The keywords field says fixed1.8.1.1, meaning that this bug is fixed in Gecko 1.8.1.1 (although it is yet to be verified.)

A quick search around leads me to http://wiki.mozilla.org/WeeklyUpdates/2006-11-27 (notes from last week's status meeting) which says Firefox 2.0.0.1 (which will use Gecko 1.8.1.1) is due to be released on Dec 14th (although it might slip depending on how many respins are required.)
Comment 44 User image Ulrich Windl 2006-12-04 00:00:32 PST
(In reply to comment #41)
> You can fix the problem yourself by disabling the 'Always use the cursor keys
> to navigate' option and the 'Use autoscrolling' option.  Works just fine for me
> now.
> 

Why should "Use cursor keys to navigate" make it impossible to use the mouse in a reasonable way? While I maybe able to disable cursor navigation, the typical user will just think and shout four letter words.
Comment 45 User image :Gavin Sharp [email: gavin@gavinsharp.com] 2006-12-04 06:51:14 PST
(In reply to comment #44)
> Why should "Use cursor keys to navigate" make it impossible to use the mouse in
> a reasonable way? While I maybe able to disable cursor navigation, the typical
> user will just think and shout four letter words.

It shouldn't, of course, which is why this bug was filed, and fixed on the 1.8 branch for Firefox 2.0.0.1.
Comment 46 User image James Rome 2006-12-04 07:50:20 PST
I filed this for SeaMonkey. Is this fixed for 1.1?
Comment 47 User image :Gavin Sharp [email: gavin@gavinsharp.com] 2006-12-04 08:43:14 PST
(In reply to comment #46)
> I filed this for SeaMonkey. Is this fixed for 1.1?

Yes.
Comment 48 User image Ria Klaassen (not reading all bugmail) 2006-12-08 14:02:21 PST
*** Bug 363213 has been marked as a duplicate of this bug. ***
Comment 49 User image Ria Klaassen (not reading all bugmail) 2006-12-10 07:49:58 PST
*** Bug 363357 has been marked as a duplicate of this bug. ***
Comment 50 User image talanwright 2006-12-15 18:06:51 PST
(In reply to comment #41)
> You can fix the problem yourself by disabling the 'Always use the cursor keys
> to navigate' option and the 'Use autoscrolling' option.  Works just fine for me
> now.
> 

It's happening to me, and I've *never* had "Always use the cursor keys to navigate" enabled in my options.  
Comment 51 User image johnmuir 2006-12-16 00:09:17 PST
Please release the fix as soon as possible. This bad behavior in basic browsing can really put people off using Firefox, especially with IE7 looking for suckers.
Comment 52 User image Ulrich Windl 2006-12-17 23:52:23 PST
There's a work-around showing how ugly the current situation really is: You click with the mouse on a link, then the link is scrolled off. But when you hit the Enter key now, the link which you can no longer see is followed. Isn't that something?

Note You need to log in before you can comment on or make changes to this bug.