Bug 40916 – Web Inspector: In Styles pane jump from a CSS property name to the value by typing colon

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Inspector (Deprecated)

[Nikita Vasilyev]

Screencast: http://screenr.com/bsm

Firebug does that too.

[Nikita Vasilyev]

Created attachment 59250 [details]
Typing colon jumps from a CSS property name to the value

[Joseph Pecoraro]

Comment on attachment 59250 [details]
Typing colon jumps from a CSS property name to the value

Looks good, feels pretty good as well!

Even with your adjustment to the blankInput regex, this still breaks
⇧⇥ (navigate backwards) from a new property. r- because of this.
I didn't investigate why.

Also, this really makes me want to use tab to go from the property
to the value. I'd strongly suggest overriding tab in this case to
do what you do for ":" when the caret is in the property.

[Nikita Vasilyev]

Created attachment 60367 [details]
⇧⇥ fixed

[Nikita Vasilyev]

Created attachment 60370 [details]
A little bit of refactoring

[Joseph Pecoraro]

Comment on attachment 60370 [details]
A little bit of refactoring

Heh, now this breaks tabbing forward right after you've created a
new property. The tests I've been doing:

  - Double click and tab though everything
  - Tab to create a new property "color: red"
  - Tab to create a new property, tab off to cancel
  - Double click to edit the last property
  - Tab to create a new property, shift tab through the list (including the selector)
  - Tab from a selector to the properties
  - Select all the text of a property, delete the text, then tab

The expected behavior for all of these should be clear. In fact, the last one
is broken in the nightlies right now.

I haven't looked too deeply at the actual code itself though. It looks good
at first glance!

[Nikita Vasilyev]

Created attachment 60379 [details]
Typing colon jumps from a CSS property name to the value

(In reply to comment #5)
>   - Double click and tab though everything
>   - Tab to create a new property "color: red"
>   - Tab to create a new property, tab off to cancel
>   - Double click to edit the last property
>   - Tab to create a new property, shift tab through the list (including the selector)
>   - Tab from a selector to the properties
>   - Select all the text of a property, delete the text, then tab

All should work, including the last one.

[Nikita Vasilyev]

(In reply to comment #2)
> Also, this really makes me want to use tab to go from the property
> to the value. I'd strongly suggest overriding tab in this case to
> do what you do for ":" when the caret is in the property.

Yeah, I also accidentally pressed tab few times when I wanted to focus on the value. It's a separate issue, so I'll do that in the new bug.

[Joseph Pecoraro]

> (In reply to comment #5)
> >   - Tab to create a new property, tab off to cancel

This wasn't working. While on the "new property" you can tab, or even
delete everything and tab, and it stays editing a "new property". Do
you feel this is an improvement? Pavel had a similar complaint with
tabbing through element attributes and decided to solve that with
tab cycling. Thoughts anyone?

[Nikita Vasilyev]

What my latest patch does: http://screenr.com/7ym
What was before: http://screenr.com/Bym
What I would like to see: http://elv1s.ru/i/webinspector-tab.png
It should act like tabIndex does.

Pictures works better than words, right?

[Joseph Pecoraro]

Comment on attachment 60379 [details]
Typing colon jumps from a CSS property name to the value

We talked about this in IRC. Behavior change was not desired, instead
new tab behavior (like cycling) should be introduced. That would be a
separate bug and patch.

[Nikita Vasilyev]

Created attachment 60471 [details]
Tab behavior restored

Another bug has been found http://screenr.com/hym and fixed.

Still no tests, but I checked through the list manually.

[Joseph Pecoraro]

Comment on attachment 60471 [details]
Tab behavior restored

Missing ChangeLog. r- for that.


> +            } else {
> +                delete section._afterUpdate;
>              }

The else should not have braces. Even though it looks ugly (to me), its the
WebKit style rules and its better to have consistent style everywhere. =)

[Nikita Vasilyev]

Created attachment 61079 [details]
ChangeLog added (sorry!)

[Joseph Pecoraro]

Doing some more extensive user testing on the colon concept itself I found
that this breaks down when you do some different selection techniques like
⌘← and ⌘A:
http://screencast.com/t/MzE0NDBjN

Have you thought about these scenarios? Would fixing them be easy/hard?

[Nikita Vasilyev]

(In reply to comment #14)

The whole approach looks weak. I think I know how to rewrite it. I'll do it next week. (it's not hard, but I don't have much free time.)

Would be great if you wrote a (failed) test for me, because I'm lost in that stuff!

[Nikita Vasilyev]

First 8 seconds of screencast is a different bug https://bugs.webkit.org/show_bug.cgi?id=41990

[Adam Barth]

Comment on attachment 61079 [details]
ChangeLog added (sorry!)

No tests.

[Alexander Pavlov (apavlov)]

Fixed with bug 50565.