Hover Error of UPDATE and NEW button on home page (FIXED)

[Axle7XStriker]

I found there was a hover error in home page in which whenever i hover over the "New" button by first going through the "Upload" button the "Upload" remains highlighted until i have traveled half of the "New" button as seen in the below image which i have also fixed by adding some code in the tree.less file.

[Axle7XStriker]

I am not getting why the Travis CI build failed. Can anyone please tell me the reason behind it.

[takluyver]

Might be a random error. I've restarted the job that failed.

[takluyver]

No, seems to be consistent. Weird. It might be that something has changed in a dependency since the tests last ran on master a few days ago.

[blink1073]

Yes, it looks like a python dependency. The first works on Ubuntu 16.04, the second does not:

conda create -y -n py27 python=2.7 notebook
source activate py27
pip install -e .[test]
python -m notebook.jstest services

conda create -y -n py27_blank python=2.7  # note: no notebook
source activate py27_blank
pip install -e .[test]
python -m notebook.jstest services

[blink1073]

Based on a diff of pip list, my guess is ipython:

$ diff py27_blank.txt py27.txt 
3c3,4
< bleach (2.1.2)
---
> backports.ssl-match-hostname (3.5.0.1)
> bleach (2.1.1)
16c17
< ipython (5.5.0)
---
> ipython (5.4.1)
23c24
< mistune (0.8.3)
---
> mistune (0.8.1)
47c48
< terminado (0.8.1)
---
> terminado (0.6)

[blink1073]

Nope, even when manually installing the same versions of all those packages, the errors persist...

[blink1073]

My only guess is that one of the installed wheels is not working but the corresponding conda package is.

[blink1073]

I also tried pip freeze > pip_reqs.txt from the working environment, and then:

conda create -y -n py27_3 python=2.7
source activate py27_3
pip install -r pip_reqs.txt
python -m notebook.jstest services

[Axle7XStriker]

I am still not able to figure out the source of the Travis CI build getting failed in that test. Did you get something related to that.

[takluyver]

No, we haven't worked it out. I just made issue #3127 about it.

[takluyver]

Reopened to rerun tests with master

[takluyver]

Tests passing. Anyone got any idea if this is the right fix for the issue with tooltips?

[Axle7XStriker]

I found out that the main reason which is causing the above problem is the input element which is gets out of bounds of the parent element because of width=100% and height=100% attribute. To solve this problem we can:-

1. Prevent input element from going out of bounds by using overflow='hidden' attribute in the parent element of input element.
2. Or using z-index attribute to give preference to "NEW" button over "UPLOAD" button. (currently implemented in this PR)

But after finding out the former solution I now think that the former one is the best solution to this problem of tooltips. What do you think?

[takluyver]

It seems like the ideal would be to fix the element so it doesn't try to go out of its bounds, but I don't understand why it does.

I can reproduce the issue in Chromium, but it's working as expected in Firefox. In Chromium, the developer tools show the Upload button in the correct rectangle, but if I hover over it and then move my mouse to the right, it stays in the hover state until I'm most of the way across the New button. To me, this feels like a bug in Chrome/ium.

@gnestor @minrk do you have time to take a look?

[minrk]

Looking into it. I think it has to do with the alternate-upload form that I think is used as the drag target.

[minrk]

Should be fixed by #3148. the invisible form was allowed to overflow beyond its container, causing the weird hover. Setting z-index moves things around, but doesn't keep the form element from spilling out.

[takluyver]

Min implemented option 1. Thanks @Axle7XStriker for noticing and investigating this!