Bug 8008 – Textarea uses the I-beam ("text") cursor when disabled, not "default"

• Component: Forms
• Status: RESOLVED CONFIGURATION CHANGED

[Aapo Laitinen]

The "textarea" HTML element does not respect the value of the "cursor" CSS property applied to it. The cursor is always the I-beam, or the equivalent of the "text" cursor. Also, when the textarea is disabled, the cursor does not change to "pointer" equivalent like it does with other fields.

Tested in Safari 2.0.3 and WebKit nightly from 2006-03-07.

[Aapo Laitinen]

Created attachment 7328 [details]
Testcase

Testcase which works fully as expected in Mozilla Firefox 1.5 and where the disabled state works as expected in Opera too. Basically:

If the field is disabled, the pointer should be consistent between various types text fields. If the "cursor" property is respected, it should be done consistently.

[Aapo Laitinen]

My description wasn't fully accurate. Apparently the "cursor" property will get applied, but in an inconsistent way depending on how fast you move the pointer. However, the part about cursor not getting changed in disabled state seems correct to me. Is this actually two separate bugs? How to split this?

[Aapo Laitinen]

Oops. I meant "default" cursor instead of "pointer". This is my first bug report, sorry for the stumbling.

In the latest nightly build of WebKit, I get the same behavior I get in Firefox 2.0. Could you please verify that the bug is fixed? Thanks!

[Aapo Laitinen]

The cursor is now "default" while hovering the blank part of a disabled field and "text" while hovering a part with some text. This is exactly like Firefox 2.0.

However, I think even the remaining use of "text" is incorrect, since you can't select the text (the I-beam cursor communicates the possibility to select or edit text, and thus there is a false affordance), and it doesn't match the standard behavior in OS X.

[Rob Buis]

Created attachment 20972 [details]
First attempt

This fixes the only problem remaining in this bug AFAICS. Since I think the test
can't be automated, I made the attached testcase a manual test.
Cheers,

Rob.

[Adele Peterson]

Comment on attachment 20972 [details]
First attempt

Do we really want to do different hit testing for read-only text controls?  Why doesn't the cursor selection code handle this?

[Rob Buis]

Created attachment 20979 [details]
move check to cursor selecting code

Moving the check into selectCursor. It seems READ_ONLY is only applied to text
controls, but I think in future this check still holds. Note that with this patch we match Opera, not FF3. I think we should decide what to do and if we decide on FF3 matching, IMHO this bug should be marked as WONTFIX. Let me know what you think.
Cheers,

Rob.

[Adele Peterson]

Comment on attachment 20979 [details]
move check to cursor selecting code

Rob and I discussed on irc that this still needs to have the i-beam cursor for readonly controls, and this check needs to just address disabled controls.

[Rob Buis]

Created attachment 21020 [details]
Better patch and more complete testcase

This patch seems to work fine. The testcase now has some cases for read-only, also what I think dhyatt meant with suitable pseudo class selectors for :disabled and :enabled.
Cheers,

Rob.

[Rob Buis]

Created attachment 21103 [details]
Better check

Aparently the m_shadowParent can be null, so add a check.
Cheers,

Rob.

[Darin Adler]

Comment on attachment 21103 [details]
Better check

What's wrong with using the I-beam cursor? Can't you select the text in a disabled textarea?

[...] renderer->containingBlock()->node()->isEnabled()

Can either of containingBlock() or node() be 0 here?

[Darin Adler]

Comment on attachment 21103 [details]
Better check

+            if ((editable || (renderer && renderer->isText() && node->canStartSelection())) && !inResizer && !scrollbar && renderer->containingBlock()->node()->isEnabled())

What guarantees that renderer->containingBlock() is non-zero?

What guarantees that renderer->containingBlock()->node() is non-zero?

Is there any way to make a regression test for this? Can we come up with a regression testing system for cursors?

Assuming the answers to all these questions are good (something, something, and some good excuse for not being able to test), then r=me.

[Mark Rowe (bdash)]

Assigning to Rob as he needs to answer Darin's questions and then update or land the patch.

[Darin Adler]

Comment on attachment 21103 [details]
Better check

Since this has been sitting around for a couple of months, and I had questions, I'm going to set the review to review- instead of review+. Rob, please set the review flag again once you answer my questions.

[Ahmad Saleem]

I am not able to reproduce this bug in Safari Technology Preview 153 on macOS 12.6 using attached testcase and it shows "pointer / default" cursor for both disabled similar to other browsers (Chrome Canary 108 and Firefox Nightly 106). Since all browsers are matching, I am going to mark this as "RESOLVED CONFIGURATION CHANGED". Please reopen, if this is reproducible. Thanks!