269548 - Find in View Source window should not activate Caret Mode

Status: RESOLVED INVALID

(Toolkit :: View Source, defect)

Description

[Timwi]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 StumbleUpon/1.998
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 StumbleUpon/1.998

Using "Find As You Type" in the "View Source" window activates the Caret Mode.

Caret Mode should not be activated when I don't explicitly press F7.

Furthermore, to disable it again, I have to press F7 twice.

Reproducible: Always
Steps to Reproduce:
Open webpage. Press Ctrl+U, then /, then type something. Then try to scroll down
by pressing the Down Arrow key.
Actual Results:  
Caret Mode is activated.

Expected Results:  
Caret Mode should not be active. I never pressed F7.

Comment 1

[Jesse Ruderman]

Caret mode is always active in View Source.  I think it's dumb, because it
interferes with ordinary scrolling shortcuts and makes it seem like you can type.

Comment 2

[Nickolay_Ponomarev]

Nevertheless, this bug as it is reported is invalid, caret mode is always-on in
view source. Do you want it to be morphed into "Don't use caret mode in View
Source"?

Comment 3

[Nickolay_Ponomarev]

Oops. Sorry it's just me being dumb. Ignore my previous comment.

Actually as of Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050325 Firefox/1.0+, comment 0 is absolutely correct, and Jesse is not -
caret is not active until you do a search.

confirming.

Comment 4

[Nickolay_Ponomarev]

d'oh.

Actually it's like this:
1. Carret browsing is always on in View source.
2. But when you open it, the focus isn't on the content area, so it makes it
seem that caret browsing is off.
3. When you use Find, focus is changed, the carret is visible.

So comments 1 and 2 were correct and the report is invalid: Find toolbar focuses
content area by design, and it doesn't actually turn caret browsing on.

Feel free to open a bug to ask to make caret mode respect browser pref.

Apologies for bugspam.

Comment 5

[Timwi]

I cannot confirm what you are claiming (the View Source window behaves much more
weirdly and unexpectedly than you have described), but anyway, I'll open a new
bug about it as you requested.

The behaviour I am seeing is this:
* When I first open the View Source window, the arrow keys scroll
  (if the focus wasn't on the content area, they probably wouldn't).
* If I press Tab, I see a dotted line around the content area, so even if the
  focus wasn't already on the content area, it is now. Yet the arrow keys still
  control the scroll bars and do not make a caret appear.
* Only if I use Find or Shift+Arrow-key, both of which creates a selection
  somewhere inside the source text, the caret behaviour starts.
* Once the caret behaviour starts, pressing Tab does not remove it, which
  indicates that other than the content area there isn't anything else that
  could have been focussed.
* If, at the very beginning when caret behaviour has not started, I press F7,
  it does get activated. This seems to indicate that it was previously off.
* If I press F7 *after* the caret behaviour has unexpectedly started, it does
  *not* turn it off. Pressing it a *second* time does. This, again, seems to
  indicate that, even though the caret behaviour is happening, the F7 handler
  thinks caret mode is actually off.

Comment 6

[Nickolay_Ponomarev]

1. Caret mode (as toggled by F7 and specified by accessibility.browsewithcaret)
is different from View Soruce "caret mode" (about which I said it was always
on). The interaction between two is very buggy, let's not talk about here. The
following assumes accessibility.browsewithcaret = false, which is default.
2. I probably use wrong terms, but focus can be *on* the browser/iframe-like
element and *in* it. Cf.: in main browser window CTRL+L,Tab,Tab puts the focus
*on* the browser element, another "Tab" moves it *in* the element (if there are
focusable elements on the current page).

When I open View Source window, the focus is neither *in* nor *on* the content area.

3. If the cursor is *in* content area, the caret is shown.
4. When the caret is visible (focus is *in*), (Shift+)Tab moves the focus *on*
content area, which effectively hides the cursor.
5. Find Toolbar shows the cursor if you enter a search term in it. However, if
you are in CTRL+F invoked, the focus seems to be in the Find Toolbar, but the
cursor is still visible -- in fact there are two cursors.
6. If FT is closed after being invoked via CTRL+F, the cursor disappears.
7. If FT is closed after being invoked via "/" or FAYT, the cursor blinks in
content area.
8. Shift+Arrow keys don't have any effect, except Shift+Down does show the caret
and also selects everything if the focus is *on* the content area.
9. Various wierdness with arrow-key navigation when in "caret mode".

It's obviously broken, but not in the way you describe. It's "almost always" in
"caret mode", in the sense that if the focus is in the content area, there's a
caret visible.

I should note that you're using a branch (1.0.x) build, and I'm using a more
recent trunk build. My build is closer to what will be Firefox 1.1. Since there
is no chance this gets fixed in 1.0.x releases, it makes more sense to test View
Source behaviour with trunk builds instead.

Comment 7

[jwq]

 Prior to Bug 254078 being fixed, the arrow keys would scroll the view source
window. That's the behaviour I'd prefer most of the time. I'd like it if it was
possible to toggle the pseudo-caret-mode in view source, in the same way that
it's possible to toggle caret browsing in a browser window.

(In reply to comment #5 by Timwi)
> ... I'll open a new bug about it as you requested.

 Was this ever done? If not, please sub a bug requesting a means of toggling
caret mode in the view source window and pop a note here with the bug number.

Comment 8

[Timwi]

It's been half a year. I don't remember.

When is Firefox 1.1 expected to be released, so that I can re-open this bug?
(Mwahaha.)