Open Bug 542313 Opened 14 years ago Updated 3 years ago

showcaret broken for browsers in 3.6

Categories

(Core :: DOM: Editor, defect, P5)

defect

Tracking

()

People

(Reporter: hans.hillen, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6

Starting with FF 3.6, showcaret="true" seems to be broken on browser elements other than the main tabbrowser.

There are two parts to this issue:

1. If caret browsing is not enabled by the user, but a separate browser element has showcaret="true", caret browsing does not work at all for that browser.
2. If caret browser IS enabled by the user, and a separate browser has showcaret=true, then the caret will be active in that browser, but it will be invisible

Reproducible: Always

Steps to Reproduce:
1. Install the test extension attached to this bug. All this extension does is add a separate browser panel at the bottom of browser.xul, containing a sample HTML document.
2.With caret browsing disabled, click on the sample content in the panel. Press the vertical arrow keys to move the caret around the content.
3. Do the same with caret browsing enabled (press F7 to enable caret browsing).
4. Don't forget to uninstall the text extension afterward.
Actual Results:  
With caret browsing disabled: Clicking on the sample content does not place the caret into it. Pressing the vertical arrow keys will just scroll the sample content.

With caret browsing enabled: Clicking on the sample content will at first appear to have no effect. However, the caret is active in the sample content, it's just not visible. You can confirm this by holding down shift in combination with the arrow keys to select some text. Then press the vertical arrow keys a few times to break the selection and move the invisible caret up or down a few lines. Again, use shift + arrow keys to make a new selection. You should see a different line being selected than the one selected before. 

Note: If caret mode is disabled, you can also make a selection using shift + arrow keys, but you can't use the arrow keys to break the selection and move the caret to a new location to start a different selection.

Expected Results:  
Caret mode should work in the browser element that has showcaret="true", regardless of whether the user has caret browsing enabled or not. The caret should be visible.

This issue started occurring in 3.6. It doesn't happen for the main browser window, only for other browsers (e.g. browsers added by extensions). The particular use case is the Firebug's Script panel, which uses the showcaret attribute to make source code navigable for keyboard users.
To see expected behavior, simply install the testcase extension to FF 3.5.*
Confirmed with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20100126 Minefield/3.7a1pre
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → 3.6 Branch
Thanks Ria. Would be great to get a regression range if possible.
Keywords: regression
Ria or Hans, could either of you find that regression range? I cannot visually confirm whether the caret is visible or not. Thanks!
Hans one more thing, can you run that firefox build and type about:buildconfig in the awesomebar, and then paste the link after "Built from" here?
I'm not seeing any caret changes recent to this changeset. Mats, Peter, any ideas?
Component: Disability Access → Editor
Product: Firefox → Core
QA Contact: disability.access → editor
Version: 3.6 Branch → unspecified
What's the regression range? We need the changeset of the last build that works too.
The last build I can find that works is built from http://hg.mozilla.org/mozilla-central/rev/90d3e6d2cbb9
Comment 6 and comment 7 say that this is the revision/build in which the bug first started happening?
Ah sorry, the revision I mentioned in comment 7 is incorrect. So the last working revision is http://hg.mozilla.org/mozilla-central/rev/90d3e6d2cbb9. The first revision that has the issue is in fact http://hg.mozilla.org/mozilla-central/rev/4430cae50dad
Ok, so http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=90d3e6d2cbb9&tochange=4430cae50dad It includes the big focus rewrite (bug 178324). Could someone bisect to find the exact revision now?
Hans if you have the time it would be much appreciated:
http://hourly-archive.localgho.st/hourly-archive2/
I have verified that a similar bug (https://bugzilla.mozilla.org/show_bug.cgi?id=546068) is caused by the cabb8925dcd3 commit, which refactors focus handling.  Unfortunately, it modified over 100 files, so it's still not well narrowed down!
I have the same problem with iframe elements in XULRunner 1.9.2.
Simply put the showcaret attribute has no effect on iframe or browser.

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: