New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 777120 link

Starred by 1 user
Status: Fixed
Owner:
█ nasko@chromium.org
Out until 24 Jan
Closed: Feb 2018
Cc:
█ sc00335...@techmahindra.com
style-bugs@google.com
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Arbitrary page can change default cursor on "about:blank"

Reported by hakerh403@gmail.com, Oct 21 2017 
UserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.62 Safari/537.36

Steps to reproduce the problem:
1. Create a HTML page and embed a pdf file containig some text.
2. Create a canvas on the same page and set `pointerEvents` to "none".
3. Place the cursor on the text inside the pdf and set canvas's `pointerEvents` to "all".
4. Navigate to "about:blank".
5. You can see that the cursor is changed. It is not like it should be on "about:blank", instead it is like in text mode.

What is the expected behavior?
The cursor on "about:blank" page (since blank page by default doesn't contain any text) should be auto, and definitely not like in text mode.

What went wrong?
As explained, the cursor is like in text mode ("cursor:text") instead of default cursor ("cursor:default"). I tried it without a pdf (using HTML elements only), but it cannot reproduce the issue.

Mozilla Firefox properly handles this situation. It resets the cursor when url is changed to "about:blank". Even more, Firefox changes the cursor when `pointerEvents` changes to "all".

I'm uploading the test case as an attachment. Hope it helps.

Did this work before? No 

Chrome version: 62.0.3202.62  Channel: stable
OS Version: 6.3
Flash Version: /
1.zip
7.1 KB Download

Comment 1 by nyerramilli@chromium.org, Oct 23 2017

Labels: Needs-Triage-M62

Comment 2 by sc00335...@techmahindra.com, Oct 23 2017

Cc: sc00335...@techmahindra.com
Components: -Blink Blink>HTML
Labels: -Type-Bug -Pri-2 hasbisect-per-revision Triaged-ET M-64 OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Owner: nasko@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce this issue on reported version 62.0.3202.62 and on latest canary 64.0.3274.0 using Windows10, Ubuntu 14.04 and Mac 10.12.6 with steps mentioned in commnet#0.

Manual Bisect Info:
===============
Good Build:55.0.2841.0
Bad Build:55.0.2842.0

You are probably looking for a change made after 414878 (known good), but no later than 414879 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/5d6411a1a10652b1a3d9ced8d744f7e427918805..d8f0aefde00132b06bd97cb17555f2ec89a0c203

Review-Url: https://codereview.chromium.org/2285883002

Suspecting same from above changelog.

@nasko: Please confirm the bug and help in re-assigning if it is not related to your change.

Thanks!

Comment 3 by tkent@chromium.org, Jan 15 2018

Components: -Blink>HTML Blink>CSS Blink>Input
I'm not sure who's owner of CSS cursor behavior. Blink>Input or Blink>CSS?

Comment 4 by kenrb@chromium.org, Feb 5 2018 

This should be fixed as of r531351, and possibly slightly earlier. I can't reproduce on trunk right now.

Comment 5 by e...@chromium.org, Feb 8 2018

Status: Fixed (was: Assigned)
Marking as fixed as per #4 and inability to reproduce on ToT.
►

Sign in to add a comment