Bug 8008 - Textarea uses the I-beam ("text") cursor when disabled, not "default"
Summary: Textarea uses the I-beam ("text") cursor when disabled, not "default"
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Rob Buis
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-27 02:18 PST by Aapo Laitinen
Modified: 2022-09-18 03:13 PDT (History)
5 users (show)

See Also:


Attachments
Testcase (741 bytes, text/html)
2006-03-27 02:27 PST, Aapo Laitinen
no flags Details
First attempt (2.64 KB, patch)
2008-05-05 12:51 PDT, Rob Buis
no flags Details | Formatted Diff | Diff
move check to cursor selecting code (2.59 KB, patch)
2008-05-06 00:20 PDT, Rob Buis
adele: review-
Details | Formatted Diff | Diff
Better patch and more complete testcase (4.89 KB, patch)
2008-05-08 10:52 PDT, Rob Buis
no flags Details | Formatted Diff | Diff
Better check (4.94 KB, patch)
2008-05-12 23:55 PDT, Rob Buis
darin: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Aapo Laitinen 2006-03-27 02:18:56 PST
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.
Comment 1 Aapo Laitinen 2006-03-27 02:27:29 PST
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.
Comment 2 Aapo Laitinen 2006-03-27 02:34:28 PST
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?
Comment 3 Aapo Laitinen 2006-04-03 00:20:41 PDT
Oops. I meant "default" cursor instead of "pointer". This is my first bug report, sorry for the stumbling.
Comment 4 mitz 2006-12-17 10:12:32 PST
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!
Comment 5 Aapo Laitinen 2006-12-18 03:11:22 PST
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.
Comment 6 Rob Buis 2008-05-05 12:51:41 PDT
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.
Comment 7 Adele Peterson 2008-05-05 13:11:29 PDT
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?
Comment 8 Rob Buis 2008-05-06 00:20:09 PDT
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.
Comment 9 Adele Peterson 2008-05-07 13:19:26 PDT
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.
Comment 10 Rob Buis 2008-05-08 10:52:52 PDT
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.
Comment 11 Rob Buis 2008-05-12 23:55:39 PDT
Created attachment 21103 [details]
Better check

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

Rob.
Comment 12 Darin Adler 2008-05-24 22:53:45 PDT
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?
Comment 13 Darin Adler 2008-06-11 15:00:21 PDT
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.
Comment 14 Mark Rowe (bdash) 2008-06-22 18:04:31 PDT
Assigning to Rob as he needs to answer Darin's questions and then update or land the patch.
Comment 15 Darin Adler 2008-10-12 15:12:07 PDT
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.
Comment 16 Ahmad Saleem 2022-09-18 03:13:33 PDT
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!