1255937 - Decide whether we want to support showcaret=true for remote xul:browsers

Status: RESOLVED WONTFIX

(Toolkit :: UI Widgets, defect)

Description

[Drew Willcoxon :adw]

showcaret=true doesn't work for remote browsers.  I haven't found out why, but do we want to even support it anymore?  I asked Neil and he wasn't sure, and he said showcaret was added for the view-source window long ago.

The reason this came up is I was trying to convert this test to browser-chrome for e10s: http://mxr.mozilla.org/mozilla-central/source/toolkit/content/tests/chrome/test_showcaret.xul  Currently the test sets showcaret on xul:iframes, and I tried setting showcaret on browsers in the main window but couldn't get the caret to show up.

Comment 1

[Neil Deakin]

To clarify, the view-source window had always had caret browsing enabled for it, such that the caret was always visible. Cursor keys would move the caret rather than scrolling the page.

I'm not sure why view source is like this; perhaps to make it more like an editor?

At some point this stopped working for view source, likely when it was moved into a tab where I'm assuming showcaret="true" isn't being applied.

Comment 2

[Panos Astithas (he/him) [:past] (please ni?)]

Ryan or Henri should know more about this.

Comment 3

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Looks like showcaret first appeared[1] in bug 394473.  It is possible to still access the old view source window for testing by setting "view_source.tab" to false and starting from a non-e10s window.  Then you can click into the source and move the caret from the keyboard like Neil says.

To be honest, this is first I've ever heard of this feature...  I don't think we need to carry over this feature into the new view source tab.  If that was the only usage of the showcaret feature, then maybe we can forget about it for e10s / remove it entirely?

If there was strong user feedback to revive this for view source tabs, I would do so by using a more complex UI in view source, like CodeMirror or similar.  Until then, I think we can live without it.

[1]: https://hg.mozilla.org/mozilla-central/rev/480b921e52ec

Comment 4

[Henri Sivonen (:hsivonen)]

Sorry, I wasn't even aware we had this kind of caret distinction for View Source. Having View Source keyboard accessible makes sense to me, but I can't say how much work we should be willing to do for it.

Passing the buck to David Bolter for keyboard accessibility comments.

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

(I'm thinking)

Comment 6

[David Bolter [:davidb] (NeedInfo me for attention)]

NI'ing Ehsan on a hunch. Ehsan do you know why we like a visible caret in view source? Is it to make it easier for power uses to do keyboard-driven selection (for copying markup)?

Comment 7

[Neil Deakin]

Some bugzilla archaeology (comment at https://bugzilla.mozilla.org/show_bug.cgi?id=252046#c3 ) suggests the caret is always on as earlier versions showed the line and column number in the statusbar. I can see how the show caret behaviour would be useful for that, but Firefox has never shown the column number so I think we can leave this bug and assume that the caret being off is the more suitable behaviour.

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

From the accessibility perspective I *think* keyboard-only users should be using our our config option "accessibility.browsewithcaret true" which seems to still work in the page source view.

Comment 9

[Panos Astithas (he/him) [:past] (please ni?)]

Sounds like there is consensus that we shouldn't fix this.