224635 - inline table editing controls should not have a pointer or arrow cursor

Status: NEW

(Core :: DOM: Editor, defect)

Description

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

When the caret is placed into a table cell, inline table editing control appear
on the border the cell. Make the mouse hover over the controls, the cursor
remains a crosshair, and that should be changed to something more usable.

Comment 1

[(no longer active)]

Presumably this could be fixed by adjusting editor/composer/src/res/EditorOverride.css.  But what cursor should we be using?

Comment 3

[rsx11m]

Since the border of a table doesn't have any specific function, the default cursor (usually the arrow) should be fine. For the controls, they have an explicit hover state, which may be sufficient already, thus the arrow might do well here too. Alternatively, maybe a "+" cursor to better target those fairly small controls?

Comment 4

[(no longer active)]

(In reply to comment #3)
> Since the border of a table doesn't have any specific function, the default
> cursor (usually the arrow) should be fine. For the controls, they have an
> explicit hover state, which may be sufficient already, thus the arrow might do
> well here too. Alternatively, maybe a "+" cursor to better target those fairly
> small controls?

I'd like to stick to the current list of supported CSS pointer values.

Comment 5

[Joris Debonnet]

I also believe the default cursor is the best way to go. But wasn't this the case in the past? I just checked in Thunderbird 14, and indeed, the default cursor appears on those controls there. Then again, it also shows the default cursor while hovering over a table cell, while the Thunderbird 21 shows the text cursor there. So clearly a recent change was made to show a text cursor whenever over the table. 

Bit strange that this bug is so old then, but perhaps it was reintroduced after having disappeared... or otherwise bug 864015 is not a duplicate after all. In any case, I personally believe the cursor over a table should NOT be a text cursor: after all, when you hover over a newline, you don't get a text cursor either. It only appears when in fact hovering over text. 

So shall we just change it back to what it used to be? The cursor over tables should simply be the default cursor.

Comment 6

[(no longer active)]

Interesting.  Can you please use mozregression to find out when this behavior regressed?

Comment 7

[Joris Debonnet]

I just checked the current release (17.0.5) which also shows the default cursor in tables (including those controls), so the text cursor has never been in a live release yet (well, not in the past few years at least). 

I will use mozregression later today to find when it was introduced.

Comment 8

[rsx11m]

Actually, TB 17.0.5 shows the default arrow cursor everywhere, including when writing in a section which just contains regular text. Thus, it appears that the reason this bug was opened for still exists, just the cursor used for the editor has changed between 17.0 and 21.0 (but apparently not in EditorOverride.css).

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #4)
> I'd like to stick to the current list of supported CSS pointer values.

I've added an MDN link for reference, if someone wants to look up which cursor shapes exist (and "+" would be "crosshair" but it looks too big for my taste).

Comment 9

[Joris Debonnet]

I see your point, and for an editor I suppose it indeed makes more sense that the text cursor appears anywhere in text sections (as in 21.0), instead of only when hovering over actual text (as in 17.0, which is more 'browser behavior'). 

So the issue is: in the past, the table controls (delete/add row/column) inherited the default cursor, which was fine. But now, it inherits the text cursor, which restricts view. 

I am convinced that overriding the CSS to use the default cursor on those controls is the best way to go (just like the resize-controls have special cursors). Using the default cursor is most consistent with any other ways of affecting content in the editor: the buttons on the toolbar (Bold, Italic,..) and of course the menu. 
The difference is of course that these table controls are inside the textfield instead of outside, but there's no precendent for this as far as I know. I don't know any other layout/design controls inside the editor (except resizing an object, which already has custom cursors). 

Since people are used to it from version 17 and before (despite the fact that this was only due to inheriting), and because it's consistent with layout/design buttons, I'd strongly suggest: default cursor.

Comment 10

[(no longer active)]

I'd like to first see why this has regressed.  Perhaps the issue is somewhere else...

Comment 11

[Joris Debonnet]

I just used mozregression to find from which date the text cursor started appearing by default in the Thunderbird Composer. 

The default cursor is used up to: 2013-01-22
The text cursor is used starting: 2013-01-25

Mozregression could not find any nightlies/dailies from 23 and 24 January.

Comment 12

[(no longer active)]

Thanks, I'll reopen bug 864015 then.

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

As far as I've tested, when I move mouse cursor over the inline table editing controls such as insert row/column before/after buttons and delete row/column buttons. They now have default (arrow) cursor. And the buttons of the resizer have proper direction's resizing cursor. Finally, over normal content in table cells, I see I-beam cursor as usual.

WFM? (I'm not sure what happened in 2013 from the comment...)