Closed Bug 351491 Opened 18 years ago Closed 18 years ago

first click in a window does not follow a link with caret browsing on

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jamesrome, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: access, fixed1.8.1.1, regression)

Attachments

(1 file)

prefs.js zipped
38.88 KB, application/x-zip-compressed
Details 
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.
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.
Do you know when this started happening?  Do you see this with a clean profile?  Do you have any extensions installed?
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.
> 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.
Attached file prefs.js zipped — 
My prefs.js file
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?
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.
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.
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.
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.
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.
I have disabled caret browsing. Seems like this should be the default. So far so good.
If the mouse gets screwed up with caret browsing on, then I think this is a legitimate bug that needs to be fixed.
OK.  This is a regression from bug 144000.  Might be a dupe of bug 334637
Assignee: general → nobody
Blocks: 144000
Component: General → Keyboard: Navigation
Keywords: regression
OS: Windows XP → All
Product: Mozilla Application Suite → Core
QA Contact: general → keyboard.navigation
Summary: first click in a window does not follow a link → first click in a window does not follow a link with caret browsing on
Version: unspecified → Trunk
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.

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
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.
*** Bug 357617 has been marked as a duplicate of this bug. ***
*** Bug 353005 has been marked as a duplicate of this bug. ***
*** Bug 348528 has been marked as a duplicate of this bug. ***
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.
*** Bug 354619 has been marked as a duplicate of this bug. ***
*** Bug 355962 has been marked as a duplicate of this bug. ***
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.

Try to disable,  apply and enable options in Options->Advanced->General
This way I "killed" this bug :)
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);
      }
   }


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.
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.
Fixed by backing out bug 144000
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
nominate blocking 1.8.1.1
the solution now is to back out the patch of bug 144000.
Flags: blocking1.8.1.1?
*** Bug 360956 has been marked as a duplicate of this bug. ***
*** Bug 359424 has been marked as a duplicate of this bug. ***
*** Bug 360412 has been marked as a duplicate of this bug. ***
*** Bug 358409 has been marked as a duplicate of this bug. ***
Flags: blocking1.8.1.1? → blocking1.8.1.1+
Keywords: access, sec508
Keywords: fixed1.8.1.1
*** Bug 361504 has been marked as a duplicate of this bug. ***
Hello all,

Please excuse me for silly question,
but where could I download 1.8.1.1 from?
(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.
*** Bug 361860 has been marked as a duplicate of this bug. ***
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).
(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


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.
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.
(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.)

(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.
(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.
I filed this for SeaMonkey. Is this fixed for 1.1?
(In reply to comment #46)
> I filed this for SeaMonkey. Is this fixed for 1.1?

Yes.
*** Bug 363213 has been marked as a duplicate of this bug. ***
*** Bug 363357 has been marked as a duplicate of this bug. ***
(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.  
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.
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?
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: