Cursor is offset in notebook in Chrome 17 on Linux #1503
Comments
|
Can you give a few more details or a screenshot. Does this always On Thu, Mar 15, 2012 at 4:26 PM, chrodan
Brian E. Granger |
|
I had a closer look at the phenomenon. The problem does not occur in Firefox 10, but always in Chrome 17. Reloading does not help. I also tried to disable some CSS properties of the code block, but the offset did not go away. Here is a screenshot where the text ("train.npy") was selected: |
|
can notebook add an export ablity................such as html file, i know I can save pages,but not so perfect..................... |
|
Are you using a non-default font size? On Fri, Mar 16, 2012 at 1:30 AM, wccgithub
Brian E. Granger |
|
no. I also tried different zoom level and the offset changes slightly but is always present |
|
I also experience this bug in Chromium on Ubuntu Linux with default Ubuntu font. It's gone in Firefox but it is also gone in Chromium on a screen with aspect ratio different than 16:9. |
|
But in that case it is related to resizing of fonts. On Fri, Mar 16, 2012 at 11:47 AM, Radek
Brian E. Granger |
|
Got this from a student that may point to a solution: When I'm working in the IPython notebook and a code section is longer than about 11 lines, the cursor and highlight position do not line up with the code I am working on. I suspected that this had something to do with the fact that keywords are bolded and that bold letters are slightly larger than normal letters. I was able to fix this issue by adding the following CSS directive to remove all bold styles.
I'm using Google Chrome on Ubuntu but the issue happens for me on Google Chrome on OS X as well. I tried to find an issue in the IPython repo on github but found none. |
|
I just accidentally created a duplicate #1745, but I added a screenshot. This bug is unfortunate, because it makes it very hard to edit larger code cells. |
|
As I indicated in #1745, I can't reproduce on Chrome 19, even with a huge cell (over 2000 lines long). Could it be a Chrome-17-specific issue? |
|
I observe the issue with Ubuntu 12.04 and Chrome 18. So it is not limited to Chrome-17, but maybe pre19 or it has something to do with Ubuntu's system fonts? |
|
I tried it on different machines and found that it requires a screen with 16:9 aspect ratio and happens only in cells with bolded keywords in them. It looks like bolded words are a few points higher than in regular font and Notebook somehow does not take it into account when calculating cursor position. |
|
I think this is an issue with CodeMirror itself and it may have to do with the fact that we have changed the CSS styling of the CodeMirror editor in the following way:
We could test to see if this is related by commenting these lines out of static/css/notebook.js. Can someone follow this up with this on the CodeMirror list. Please mention that setting the |
|
I dug into this a bit in investigating all the reasons cells were jumping around. It is caused by Chrome choosing fonts for which the bold and italic variants do not have the same height as the normal variant. On my computer (Ubuntu 12.04, Chrome 20 beta), Chrome is choosing "Courier New" as the monospaced font, while Firefox is choosing "Bitstream Vera Sans Mono". The Bitstream fonts do not have this problem that different weights have different heights, which is why Firefox did not display the problem. You can fix it in Chrome too by changing its font to the Bitstream one. So technically, this is a browser bug, and I was unable to find a way to fix it using CSS. Fixing line-height, font-size, etc, do not work to fix this bug. The only thing that fixes it is to avoid bold and italic fonts as pointed out by @ellisonbg, or to make an explicit list of fonts using CSS font-family. Fonts which do not have the problem on my computer include:
Fonts that do have the problem on my computer include:
Perhaps someone on windows or mac can tell us which fonts do or don't have the problem? I find the easiest way is to type two or more lines that do not contain any bold/italic keywords, and add "print" or something which gets bolded to the first line. The second you hit the 't' of 'print', the text below it will shift down by 1px or so. You may have to zoom in, making to font larger, to see this. Simultaneously, choose the mono font in your browser settings. Change these lines in notebook.css to fix it, using the fonts above, or some subset thereof... .CodeMirror pre { What is the reasoning behind the odd 1.231 font size (also in boilerplate.css)? Is it related to this bug? |
|
Wow, thanks for looking around at all of this. Some points:
Whew, this is a very tough choice. What to others think @fperez, @minrk, @Carreau?
I am using the YUI CSS font stuff to size text in a consistent way across browsers: |
|
On Thu, Jun 7, 2012 at 12:15 PM, Brian E. Granger
Tough one; the reason I dislike hardcoding font lists is because it I get unbelievably annoyed when sites hardcode monospaced fonts |
|
Tough choice. It seems like if we want allow users to choose, the first choice should be 'monospace', and let users configure their browsers/systems as they may. There's no typeface blacklist, is there? Hardcoding Fernando's preference doesn't make a lot of sense to me. |
|
All I was saying is that if we're going to make a hardlist (which I don't like), I want it to be the one I can live with ;) I think the problem is that if we say 'monospace', Chrome defaults to Courier New, which if I understand things correctly, happens to have this bug (in addition to be horrible and suck). |
|
Fernando Perez [reply@reply.github.com] wrote:
Yes. 'monospace' as the first option is not viable. As a desperate fallback Another alternative would be to serve up a reasonable font itself. I see no way http://www.fontsquirrel.com/fontfacedemo/Bitstream-Vera-Sans-Mono Cheers, Bob McElrath "The individual has always had to struggle to keep from being overwhelmed by |
|
As long as a served font doesn't override my own custom choice, I'm fine with it. But if a served font prevents me from getting the font I've configured as my monospace font from displaying, then no. |
|
It is impossible for force any monospace fonts without pissing people off. Programmers are far too attached to their coding typefaces. (for instance, forcing Consolas would piss me off, and anything else would do the same for Fernando). That seems like a complete non-starter, so I think the font-family must be left as monospace. I've tried to replicate the bug with CodeMirror theme demos and can't seem to do it, even with Courier New, so I think it's something we are doing. |
|
Ah, then that means there may be a hope of fixing it... Thanks for digging further, Min. |
|
Min RK [reply@reply.github.com] wrote:
Well then so far the only solution is to turn off bold and italics. It may be possible to detect the presence of this bug... there's a trick used by http://stackoverflow.com/questions/1134586/how-can-you-find-the-height-of-text-on-an-html-canvas Cheers, Bob McElrath "The individual has always had to struggle to keep from being overwhelmed by |
|
Min, great tracking that point down. I think the one thing we might be doing is setting the font size differently in the CodeMirror editor. It was actually quite subtle to get the font in the CodeMirror cell to match things like the prompt's font size. I used the YUI font stuff because it simplified everything, but it may not play well with how CodeMirror works. |
|
It can be fixed with vertical-align:bottom on the span tag. See my new pull request #1883. I'm going to go change fonts now, because I hate Courier too...triply so now, having wasted so much time on the stupid thing. |
|
On Thu, Jun 7, 2012 at 10:41 PM, Bob McElrath
Awesome! Thanks a ton for all your patience in hunting this down... Cheers, f |
|
So has this one been fixed? |
|
Closed by #1883. |
|
Yup, sorry: I failed to put the closing tag in the merge message, thanks for spotting it! |
|
No problem, just doing my periodic skim of Issues, to see if we've missed some. I've also been bumping various we obviously won't get to for 0.13 over to 0.14. |
|
Yup, awesome. I've also been doing triage and will email the list |
|
I'm using IPython 0.13.2 and still seeing this issue (but the font-weight force fixed it). Any chance you could add a note about this to the docs? (maybe there's even a way to use display + CSS to force it so you could just add a code snippet). |
|
@jtratner can you see if you still have this issue in 1.0, which was released in August? If you still see the issue, please open a new bug for it (referencing this one). Thanks |
|
I will check (I don't recall seeing it though). Clearly searching for the On Tue, Oct 15, 2013 at 2:48 PM, Paul Ivanov notifications@github.comwrote:
|
Using the current development version of the notebook I notice a vertical offset of the cursor in code cells. The offsets gets bigger the more lines the cell contains. This offset makes editing code unfeasible. As the effect does not occur in markdown cells, I assume that the reason is the java script code editor. I am using Chrome 17.0 on Linux.
The text was updated successfully, but these errors were encountered: