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

Issue 610868 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit 29 days ago
Closed: Jul 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

editing values has 4 keystroke limit

Reported by elean...@gmail.com, May 10 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36

Steps to reproduce the problem:
1. Visit a website being developed locally, not remote
2. pick any dom element
3. edit any numerical attribute in the right-hand bar (eg, padding or margins)
4. press up arrow and down arrow repeatedly, more than 5-6 times.

What is the expected behavior?
That I can keypress the up and down arrows as many times as I want to edit the value of the padding or margins.

What went wrong?
after 4 keypresses, it loses focus and stops changing the value.  It just basically shifts the focus and stops working.  I have to physically place the pointer back into the dev tools in order to keep editing.

Did this work before? Yes yesterday

Chrome version: 50.0.2661.94  Channel: stable
OS Version: OS X 10.11.4
Flash Version: Shockwave Flash 21.0 r0

obv, this is extremely stressful and frustrating.
I'm sad that I can't repro this on a mainstream site.  I'm using a php site through a VM
 

Comment 1 by elean...@gmail.com, May 10 2016

This behaviour doesn't happen in an incognito tab;
Though it DOES happen after I uninstall and reinstall Chrome.

I do have errors in my browser that pertain to not have sass mapping files correctly installed.
Perhaps that is a factor?  Not sure.
This may somehow be my fault, but I am confused as to how my code could be interfering w dev tools

Comment 2 by caseq@chromium.org, May 10 2016

Components: -Platform>DevTools Platform>DevTools>HTML
Owner: lushnikov@chromium.org
Status: Assigned (was: Unconfirmed)

Comment 3 by elean...@gmail.com, May 10 2016

GOT IT!

Here's what's happening, and I didn't know, because I already had my console window open, but minimized beyond view-

whilst editing a style in the dev tools, it seems to trigger a search for .map files, of which I don't have the correct setup right now, and I know this;

It makes sense that it's good to search for that, but if one doesn't have the console window fully visible, it won't be apparent that this is happening.

In theory, a person with faulty/missing sass .map files, without having their console fully visible, will be oblivious to, and not understand why, the focus is shifting away from the styles editor for these errors.

I guess this really is a question of design, instead of an explicit bug.

For posterity, this is a potential pain point for users, and it might be reasonable to examine if feedback can be seen in the styles window if focus is shifting away for an error in the console. (maybe flip it red or show a warning to check the console window)
Simlpy not stealing focus when displaying error in drawer will eliminate all the friction.
Status: Fixed (was: Assigned)
Looks like this is fixed. 

Sign in to add a comment