Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Cursor over line numbers is oversized (Chrome 51) #8708

Closed
bpasero opened this issue Jul 4, 2016 · 9 comments
Closed

Cursor over line numbers is oversized (Chrome 51) #8708

bpasero opened this issue Jul 4, 2016 · 9 comments
Assignees
Labels
bug Issue identified by VS Code Team member as probable bug verified Verification succeeded

Comments

@bpasero
Copy link
Member

bpasero commented Jul 4, 2016

Seems like the same issue as microsoft/monaco-editor#5

editors

@bpasero bpasero added bug Issue identified by VS Code Team member as probable bug editor labels Jul 4, 2016
@alexdima alexdima assigned bgashler1 and unassigned alexdima Jul 4, 2016
@alexdima
Copy link
Member

alexdima commented Jul 4, 2016

@bgashler1 For the standalone editor, I removed this style. As you added these CSS rules, maybe you know what's going on?

@bpasero bpasero added this to the July 2016 milestone Jul 4, 2016
bpasero added a commit that referenced this issue Jul 4, 2016
@bgashler1
Copy link
Contributor

bgashler1 commented Jul 21, 2016

@alexandrudima it seems that we've gone back to an older Electron version and that this is not currently an issue? I noticed Ben uncommitted the CSS and there don't seem to be problems. Will close for now, since I cannot reproduce in VS Code on Mac with a Retina display. Please reopen if it's still an issue.

A little background: the CSS rules with the 2x sized image was a workaround for this Chrome bug, which causes SVG cursors to be pre-rasterized (as if they were a png) before being rendered, causing pixelation on hdpi screens.

@jrieken jrieken added the verified Verification succeeded label Jul 28, 2016
@bpasero
Copy link
Member Author

bpasero commented Aug 5, 2016

@bgashler1 we will hit this issue again eventually once we update. Note that the next jump would be to Chrome 52, not sure if that would make a difference.

bpasero added a commit that referenced this issue Aug 7, 2016
@bpasero
Copy link
Member Author

bpasero commented Aug 7, 2016

Still happens in Chrome 52, reopening.

@bpasero bpasero reopened this Aug 7, 2016
@bpasero bpasero removed the verified Verification succeeded label Aug 7, 2016
@bpasero bpasero modified the milestones: August 2016, July 2016 Aug 7, 2016
@bpasero bpasero modified the milestones: Backlog, August 2016 Aug 20, 2016
@bpasero
Copy link
Member Author

bpasero commented Aug 20, 2016

No Electron update for August...

@brunnopleffken
Copy link
Contributor

@bpasero Not trying to ignore the issue, but just giving my two cents: really worth being stuck in an old version of Chromium and an equally old "zero-point-x" version of Electron because of an inverted cursor?

Reading their changelog, you're missing a bunch of new features and improvements: https://github.com/electron/electron/releases

@bpasero
Copy link
Member Author

bpasero commented Aug 24, 2016

@brunnopleffken this issue does not block our Electron update, but this one electron/electron#5715

Feel free to provide a PR to fix this issue for them 👍

bpasero added a commit that referenced this issue Aug 30, 2016
bpasero added a commit that referenced this issue Sep 14, 2016
* use electron 1.3.4

* ATOM_SHELL_INTERNAL_RUN_AS_NODE => ELECTRON_RUN_AS_NODE

* OSS input

* update electron.d.ts

* workaround for #8708

* bump oniguruma and chokidar with custom fsevents

* build with appveyor config from master

* oops, still use ELECTRON_RUN_AS_NODE

* use electron 1.3.5

* optional fsevents

* add cat.exe to workaround output issues

* use cat for tests

* remove some now obsolete ELECTRON_NO_ATTACH_CONSOLE

* also pipe output to cat for code.sh on windows

* unset ELECTRON_RUN_AS_NODE for appveyor

* fix tfs builds?

* fix build

* fix build?

* use cat only when running tests locally
@bpasero bpasero modified the milestones: September 2016, Backlog Sep 17, 2016
@emeryao
Copy link

emeryao commented Sep 17, 2016

I got a TEMPORARY solution for this issue:
change the css class of .monaco-editor .margin-view-overlays .line-numbers in file workbench.main.css
with the style below:

cursor: -webkit-image-set(url("data:image/svg+xml;charset=utf-8,%3Csvg xmlns='http://www.w3.org/2000/svg' height='45' widht='30' viewBox='0 0 15 21'%3E%3Cpath fill='%23fff' stroke='%23000' d='M14.5 1.2L1.9 13.8h5.2l-2.6 5.3 3.2 1 2.6-5.2 4.2 3.1z'/%3E%3C/svg%3E") 2x) 30 0,default;

the key of this TEMPORARY solution is the height and width attribute of the svg tag.

@bgashler1
Copy link
Contributor

bgashler1 commented Sep 19, 2016

@emeryao thanks for discovering the width and height issue. Pushing a commit that fixes this at the root of the problem.


I also want to mention to anyone else who may experience this same problem on another project that Adobe Illustrator does not save width and height attributes to SVG files by default. They only use viewbox.

I actually couldn't even get a custom image cursor to show up in Chromium version 52 until I added these attributes to the SVG files—Chromium would instead always show whatever fallback cursor I had in the CSS. For example, in the case of cursor: url('flipped-cursor-2x.svg'), crosshair; it would always use cross hair, and if I took crosshair off, it would say that I had an "invalid property value".

bgashler1 added a commit that referenced this issue Sep 19, 2016
Adds missing height and width attributes to the svg cursors that are required for Chrome to render them properly.
bgashler1 added a commit that referenced this issue Sep 19, 2016
@bpasero bpasero added the verified Verification succeeded label Sep 28, 2016
@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 18, 2017
# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
bug Issue identified by VS Code Team member as probable bug verified Verification succeeded
Projects
None yet
Development

No branches or pull requests

6 participants