The default bug view has changed. See this FAQ.

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

RESOLVED FIXED

Status

()

Core
Keyboard: Navigation
RESOLVED FIXED
11 years ago
10 years ago

People

(Reporter: James Rome, Unassigned)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
x86
All
access, fixed1.8.1.1, regression, sec508
Points:
---
Bug Flags:
blocking1.8.1.1 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

38.88 KB, application/x-zip-compressed
Details
(Reporter)

Description

11 years ago
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.
(Reporter)

Comment 1

11 years ago
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

11 years ago
Do you know when this started happening?  Do you see this with a clean profile?  Do you have any extensions installed?
(Reporter)

Comment 3

11 years ago
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

11 years ago
> 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.
(Reporter)

Comment 5

11 years ago
Created attachment 240017 [details]
prefs.js zipped

My prefs.js file
(Reporter)

Comment 6

11 years ago
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

11 years ago
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

11 years ago
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.
(Reporter)

Comment 9

11 years ago
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.
(Reporter)

Comment 10

11 years ago
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

11 years ago
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.
(Reporter)

Comment 12

11 years ago
I have disabled caret browsing. Seems like this should be the default. So far so good.
(Reporter)

Comment 13

11 years ago
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

11 years ago
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

Comment 15

11 years ago
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

11 years ago
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

11 years ago
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

11 years ago
*** Bug 357617 has been marked as a duplicate of this bug. ***

Comment 19

11 years ago
*** Bug 353005 has been marked as a duplicate of this bug. ***

Comment 20

11 years ago
*** Bug 348528 has been marked as a duplicate of this bug. ***

Comment 21

11 years ago
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. ***

Comment 24

11 years ago
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

11 years ago
Try to disable,  apply and enable options in Options->Advanced->General
This way I "killed" this bug :)

Comment 26

11 years ago
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

11 years ago
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

11 years ago
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

11 years ago
Fixed by backing out bug 144000
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Comment 30

11 years ago
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

Updated

11 years ago
Keywords: fixed1.8.1.1
*** Bug 361504 has been marked as a duplicate of this bug. ***

Comment 36

11 years ago
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. ***

Comment 39

11 years ago
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

11 years ago
(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

11 years ago
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

11 years ago
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

11 years ago
(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

11 years ago
(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.
(Reporter)

Comment 46

11 years ago
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. ***

Comment 50

10 years ago
(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

10 years ago
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

10 years ago
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?
You need to log in before you can comment on or make changes to this bug.