Bug 165377 - [pointer-lock] Cursor should become visible when exiting pointer-lock via ESC key.
Summary: [pointer-lock] Cursor should become visible when exiting pointer-lock via ESC...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Jer Noble
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2016-12-05 09:14 PST by Jer Noble
Modified: 2016-12-07 11:31 PST (History)
10 users (show)

See Also:


Attachments
Patch (5.56 KB, patch)
2016-12-05 09:23 PST, Jer Noble
no flags Details | Formatted Diff | Diff
Patch for landing (6.66 KB, patch)
2016-12-05 10:56 PST, Jer Noble
no flags Details | Formatted Diff | Diff
Patch for landing (6.63 KB, patch)
2016-12-05 15:26 PST, Jer Noble
no flags Details | Formatted Diff | Diff
Follow-Up Patch (1.88 KB, patch)
2016-12-07 08:32 PST, Jer Noble
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jer Noble 2016-12-05 09:14:57 PST
[pointer-lock] Cursor should become visible when exiting pointer-lock via ESC key.
Comment 1 Jer Noble 2016-12-05 09:23:09 PST
Created attachment 296146 [details]
Patch
Comment 2 Darin Adler 2016-12-05 09:30:26 PST
Comment on attachment 296146 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=296146&action=review

> Source/WebCore/page/PointerLockController.h:50
> +    enum ForceCursorVisibleFlag {
> +        DoNotForceCursorVisible,
> +        ForceCursorVisible,
> +    };

I suggest using an enum class:

    enum class ShouldForceCursorVisible { Yes, No };

I also suggest defining this on a single line instead of four lines.

> Source/WebCore/page/PointerLockController.h:52
>      void elementRemoved(Element*);

These functions that take pointers are so old fashioned. They should take references unless there is some reason they need to work with null.
Comment 3 Darin Adler 2016-12-05 09:31:07 PST
Comment on attachment 296146 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=296146&action=review

> Source/WebCore/page/PointerLockController.h:51
> +    void requestPointerUnlock(ForceCursorVisibleFlag);

I suggest two different functions instead of one function with a flag. We can use the flag internally, but it is less clear for callers than two separate functions with good names would be.
Comment 4 Jer Noble 2016-12-05 10:56:20 PST
Created attachment 296161 [details]
Patch for landing
Comment 5 Jon Lee 2016-12-05 15:17:42 PST
rdar://problem/29081718
Comment 6 Jer Noble 2016-12-05 15:26:16 PST
Created attachment 296201 [details]
Patch for landing
Comment 7 WebKit Commit Bot 2016-12-05 16:47:35 PST
Comment on attachment 296201 [details]
Patch for landing

Rejecting attachment 296201 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-02', 'build', '--no-clean', '--no-update', '--build-style=release', '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit

Last 500 characters of output:
x86_64/RenderButton.dia -c /Volumes/Data/EWS/WebKit/Source/WebCore/rendering/RenderButton.cpp -o /Volumes/Data/EWS/WebKit/WebKitBuild/WebCore.build/Release/WebCore.build/Objects-normal/x86_64/RenderButton.o

** BUILD FAILED **


The following build commands failed:
	CompileC /Volumes/Data/EWS/WebKit/WebKitBuild/WebCore.build/Release/WebCore.build/Objects-normal/x86_64/PointerLockController.o page/PointerLockController.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler
(1 failure)

Full output: http://webkit-queues.webkit.org/results/2629953
Comment 8 Jer Noble 2016-12-06 08:41:33 PST
Committed r209394: <http://trac.webkit.org/changeset/209394>
Comment 9 Darin Adler 2016-12-06 18:55:07 PST
Comment on attachment 296201 [details]
Patch for landing

View in context: https://bugs.webkit.org/attachment.cgi?id=296201&action=review

> Source/WebCore/page/PointerLockController.cpp:157
> +    if (m_forceCursorVisibleUponUnlock)
> +        m_page.chrome().client().setCursorHiddenUntilMouseMoves(false);

Shouldn't we set m_forceCursorVisibleUponUnlock back to false here?
Comment 10 Jer Noble 2016-12-07 07:12:03 PST
Comment on attachment 296201 [details]
Patch for landing

View in context: https://bugs.webkit.org/attachment.cgi?id=296201&action=review

>> Source/WebCore/page/PointerLockController.cpp:157
>> +        m_page.chrome().client().setCursorHiddenUntilMouseMoves(false);
> 
> Shouldn't we set m_forceCursorVisibleUponUnlock back to false here?

Gah, you're right. I'll fix that s in a follow-up.
Comment 11 Jer Noble 2016-12-07 08:32:48 PST
Reopening to attach new patch.
Comment 12 Jer Noble 2016-12-07 08:32:54 PST
Created attachment 296392 [details]
Follow-Up Patch
Comment 13 WebKit Commit Bot 2016-12-07 11:31:12 PST
Comment on attachment 296392 [details]
Follow-Up Patch

Clearing flags on attachment: 296392

Committed r209464: <http://trac.webkit.org/changeset/209464>
Comment 14 WebKit Commit Bot 2016-12-07 11:31:18 PST
All reviewed patches have been landed.  Closing bug.