Closed Bug 505732 Opened 15 years ago Closed 13 years ago

website triggers caret browsing mode

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 669026

People

(Reporter: asac, Unassigned)

References

Details

Attachments

(1 file)

Snapshot of Planet Mozilla from 2011-07-27, which triggers invisible Caret Browsing
492.28 KB, application/xhtml+xml
Details
LP: https://bugs.launchpad.net/bugs/107247 Steps to reproduce: 1. In Firefox or Epiphany, open any launchpad bug page, such as the one above. 2. Wait for the Subscribers box to finish loading. 3. Press the Up or Down arrow keys. Result: firefox switches to caret browsing mode. We see this on ffox 3.0/3.5 and mozilla-central builds.
Version: unspecified → Trunk
Looks like the linked site changed something since this bug was filed so that it no longer qualifies as a test case. Does anyone have another test case?
hmmm. i think you need to be member of the launchpad beta testers to see the version affected. i will try to get something ...
got more info: seems it should also happen if you are not in the launchpad beta testers. however, i was told that you need to be logged in to reproduce.
maybe also helpful that this commit makes it goes away: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/9000
Sorry, but there's no obvious link between that commit and caret browsing.
maybe also check https://bugs.edge.launchpad.net/bugs/404088 (and https://bugs.edge.launchpad.net/bugs/392138) which was the bug that caused the above fix for this as a side-effect to land. They are talking about focusing some hidden element. does that ring a bell?
No, but I'll CC enndeakin as being the person who knows most about focusing...
> Result: firefox switches to caret browsing mode. That seems unlikely. Do you actually mean that caret browsing is enabled (and that the preference is set), or just that the caret appears? Is the text editable? Please describe what actually happens. A testcase is needed here as well.
we are working on a testcase ... But it really triggers caret browsing. I just tried and this are the instructions 1. caret browsing disabled (accessibility.browsewithcaret=false) 2. log into launchpad and go to the bug page and wait till the subscribers are loaded 3. press the up and/or down key ( Expected result: page scrolls Actual result: page doesn't scroll as expected - feels like a missing focus. ) 4. click on the page (i clicked in the title) 5. use arrow keys Expected result: page scrolls Actual result: a caret appears which you can move on the document using the arrow keys. however, a caret appears and the arrow key move it through the document (which i refer to as caret browsing).
> 4. click on the page (i clicked in the title) > 5. use arrow keys Also, sometimes you dont need those two extra steps (In reply to comment #8) > that the preference is set), or just that the caret appears? Is the text > editable? no its not editable. you can just move the caret through the document using arrow keys.
This is still happening today (2009-08-07) on the main (deployed) Malone instance, eg. the URL: https://bugs.launchpad.net/malone/+bug/392138 exhibits the behaviour on about 50% of page loads. Yes, just to confirm, the page *is* triggering the caret to appear in between the characters in the text, and that: accessibility.browsewithcaret=false I reproduced this first time, by opening the above URL, PageDn, PageDn, PageDn (until at bottom), PageUp, PageUp, PageUp (until at top), and which point the PageUp/Down stopped working and the caret had appeared, movable via the Up/Down arrow keys.
Repeated tests to try to reproduce it (each started from a fresh page load): 1. Yes: PageDn (x3), PageUp (x3), page "locked", caret there 2. Yes: PageDn (hold), PageUp (hold), page locked, click for caret to appear 3. No. 4. Yes: PageUp (repeat), PageDn (repeat), PageUp (repeat), PageDown (repeat), Arrow Down, caret on 5. Yes: Hold Down Arrow whilst page loading, Page jumps back (almost) to top, page "locked", click for caret to show 6. Yes: Hold Down Arrow whilst page loading, scroll down, jump back to top, scolls down again, jump to top again, page locks; click to different tag, click back again, page unlocks. 7. Yes: Page locked itself, click for caret to appear, change tabs and back again, page unlocked. 8. Yes: Hold Arrow Down whilst page loading, page jumped + locked, change tabs and back to unlock. 9. Yes: Hold Up Arrow whilst page loading, page locked 10. Yes: Hold Page Down whilst page loading, page jumped to top and locked, click for caret to appear. So, nine times out of ten, reproducibility. The most reliable way (although not the only way) appears to be to hold down one of the scrolling (Arrow or Paging) keys whilst the page is loading. And that changes tabs clears caret browsing mode. The Downstream bug report has that produce cross-platform (and cross browser) so appears to be Gecko itself kicking into caret mode, rather than the browser interface enabling it.
It appears that bug #289632 ("Caret browsing halts keyboard focus on javascript links") may be related to this. There are certainly <a href="..." onclick="..."> elements in the Launchpad page in question.
Still can't reproduce this.
Keywords: testcase-wanted
Thanks Neil, This is still 100% reproducible by my end, simply by holding the Down Arrow key down whilst loading the page of any Launchpad Bug report. *Whilst logged in*. The being *logged in* bit is crucial, as otherwise the box that is triggering this caret behaviour will not be made editable. Is there anything further that can myself or other can do to assist? -Paul
http://launchpadlibrarian.net/30122852/prevent-scrolling.html is an attachment to the downstream bug which exhibits a similar problem, although it's not 100% the same as the Launchpad issue. Apparently Paul was unable to isolate the precise HTML/CSS/JavaScript combo which would allow you to reproduce fully, but his attachment should at least show you that something is wrong, and that this is reproducible. (See also the comments at https://bugs.launchpad.net/malone/+bug/107247/comments/28)
I've been noticing this same behavior on linux when navigating through google search results with the keyboard. Pressing PgUp/PgDn sometimes enables caret browsing; the caret shows up (sometimes not immediately visible) and PgUp/PgDn stop functioning (movement of the caret with the cursor keys still works). Pressing F7 and selecting "No" restores PgUp/PgDn behavior to normal. The caret seems to only be enabled for the tab with the search results; other tabs are unaffected. Switching tabs or windows and coming back to the search results is not sufficient to turn off caret browsing for that tab. The problem is intermittent; I have not yet been able to reproduce it at will.
I also have occasionally had this issue. Happened again just today after a quick Google search, page down was no longer working and I discovered caret browsing had been enabled. Pressing F7 results in the prompt box ("Pressing F7 ... Do you want to turn caret browsing on?") and I press no which causes it to disable and allows page up/down and the arrow keys to work once again. I tried repeating my google search but it did not enable again the second time. I've not been able to reproduce it with any consistency but it does happen occasionally.
I just encountered this issue myself, on Planet Mozilla (planet.mozilla.org). I visited Planet Mozilla, and noticed that I couldn't seem to use the arrow keys to scroll. Poking at it further, I found that if I held down an arrow for a while, the page would start scrolling in that direction after a bit; if I stopped, and then pressed in the same direction, it would scroll in that direction immediately, but reversing direction required waiting a bit. This felt a lot like caret browsing; however, caret browsing was not actually turned on. I pressed F7 to turn on caret browsing, and after confirming that in the dialog, the caret appeared exactly where the scrolling behavior suggested it would. (For example, if I pressed down until the page started scrolling, then pressed up a couple of times, then turned on caret browsing, the caret would appear a couple of lines above the bottom of the window.) Build identifier: Mozilla/5.0 (X11; Linux x86_64; rv:7.0a2) Gecko/20110715 Firefox/7.0a2
Just in case something changes, I'll attached a snapshot of Planet Mozilla. I've confirmed that the problem occurs with only the HTML present, without the CSS, scripts, images, or videos.
And I can confirm that clicking on the attachment and browsing it here on Bugzilla still triggers the same behavior.
Likely caused by the post that uses contenteditable.
(In reply to comment #23) > Likely caused by the post that uses contenteditable. Indeed.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
I also noted that middle-clicking links on Planet Mozilla doesn't work. Same bug?
(In reply to comment #25) > I also noted that middle-clicking links on Planet Mozilla doesn't work. > Same bug? No, please file one?
mbrubeck filed it: bug 674770
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: