Open
Bug 542313
Opened 14 years ago
Updated 3 years ago
showcaret broken for browsers in 3.6
Categories
(Core :: DOM: Editor, defect, P5)
Core
DOM: Editor
Tracking
()
NEW
People
(Reporter: hans.hillen, Unassigned)
References
Details
(Keywords: regression)
Attachments
(1 file)
56.04 KB,
application/x-xpinstall
|
Details |
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.
Reporter | ||
Comment 1•14 years ago
|
||
Reporter | ||
Comment 2•14 years ago
|
||
To see expected behavior, simply install the testcase extension to FF 3.5.*
Comment 3•14 years ago
|
||
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
Comment 4•14 years ago
|
||
Thanks Ria. Would be great to get a regression range if possible.
Updated•14 years ago
|
Keywords: regression
Comment 5•14 years ago
|
||
Ria or Hans, could either of you find that regression range? I cannot visually confirm whether the caret is visible or not. Thanks!
Reporter | ||
Comment 6•14 years ago
|
||
This started happening in http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/06/2009-06-11-04-mozilla-central/firefox-3.6a1pre.en-US.win32.installer.exe
Comment 7•14 years ago
|
||
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?
Reporter | ||
Comment 8•14 years ago
|
||
Built from http://hg.mozilla.org/mozilla-central/rev/90d3e6d2cbb9
Comment 9•14 years ago
|
||
I'm not seeing any caret changes recent to this changeset. Mats, Peter, any ideas?
Updated•14 years ago
|
Component: Disability Access → Editor
Product: Firefox → Core
QA Contact: disability.access → editor
Version: 3.6 Branch → unspecified
Comment 10•14 years ago
|
||
What's the regression range? We need the changeset of the last build that works too.
Reporter | ||
Comment 11•14 years ago
|
||
The last build I can find that works is built from http://hg.mozilla.org/mozilla-central/rev/90d3e6d2cbb9
Comment 12•14 years ago
|
||
Comment 6 and comment 7 say that this is the revision/build in which the bug first started happening?
Reporter | ||
Comment 13•14 years ago
|
||
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
Comment 14•14 years ago
|
||
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?
Comment 15•14 years ago
|
||
Hans if you have the time it would be much appreciated: http://hourly-archive.localgho.st/hourly-archive2/
Comment 16•14 years ago
|
||
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!
Comment 17•14 years ago
|
||
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.
Comment 18•3 years ago
|
||
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.
Description
•