Build ID: 2000050608 As of now, the standard win32 I-Beam cursor only appears over places in the textbox (and URL bar) where there's actual text. Everywhere else, there's the arrow cursor. This feels kind of awkward to Windows users who are used to seeing I-beam cursors extend to the length of textboxes, rather than just over the text that they contain. At the very least, I think completely empty textboxes should display the I-Beam cursor, indicating to the user that they may type there (current behavior is the arrow).

assigning to jfrancis to investigate

mike, simon, any clues? The same cursor feedback is true for layout in general. I guess we want to do something different if we are over an editor.

I think some CSS for HTML inputs would fix this. I'll check it out.

The situation here has gotten a little better. All HTML textboxes now atl least have the I-Beam cursor over their entire length (whether they have text or not) until they get focus, at which point they display the same before as initially reported.

Thanks to mjudge's enderlite, this now works great in the browser (on windows, anyways - don't know if ender lite's been turned on for other platforms yet). still not in composer, though.

Not in textareas, either. Regarding Composer: the cursor is an I-beam where there is actual text, as in the browser, except for the HTML source pane, where even the scrollbars have an I-beam cursor.

m19

moving to future and adding helpwanted keyword

This appears to work in textfields (and the URL bar) but not textareas. Perhaps Simon forgot to apply is input CSS to textareas?

Updating summary (textbox -> textarea)

I just fixed this on my PC by changing html.css: the textarea { } section needs the same cursor: text; as the input { } section.

Attach a patch, if you please :)

r=blake on the patch, since neil made it. simon, please sr= and let's get this in.

Simon?

What happens when the cursor is over the scrollbar? Does it change to an arrow? If so, sr=sfraser

No but that's not the fault of html.css so I filed bug 61921 to cover that. The workaround is to style the scrollbar cursor in xul.css i.e. scrollbar { cursor: default; }

Fix checked in, since that is indeed a separate bug (and kin says he already has one like 61921 on his list)

umm.. after this fix, the ibeam cursor is suddenly "everywhere" there is text at all. On a plain webpage without forms, for instance. Is this the expected behaviour?

??? I just downloaded a win32 nightly and I don't see it. What do you mean "everywhere" there is text? The cursor is usually the I-Beam over plain webpage text. Can you post a screenshot of what you're seeing....?

Couldn't find a screenshooter that would include cursors. But seems you understand what i mean. Thing is: I though linux till now has showed the *arrow* when over text on wepages, while the *ibeam* has only been used where user could actually input something. Perhaps I'm even wrong. I like the ibeam anyways - makes it easyer to know where potential selections actually start. Just had to ask.

> umm.. after this fix, the ibeam cursor is suddenly > "everywhere" there is text at all. On a plain > webpage without forms, for instance. Is this the > expected behaviour? Yes. I-beam does not indicate editability, but selectability. Therefore I-beam should be displayed wherever there is selectable text. (not on submit buttons, drop-down boxes, images, non-text white space, scroll bars, etc.)

verified in 1/24 build.