Bug 99259 – Web Inspector: Sass can only resolve same folder paths

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

[Paul Irish]

A few ways to trigger this issue

Use a folder structure like 
|- css\*
\- sass\*

Or one like
\-css\*
  \-sass\*

1) Compile sass with line numbers.

2) above a block of styles, view the filename
2a) Bug: it may appear as "css/..:213" which doesn't give the source filename

3) click the file link

4a) on the file:/// protocol, a new tab opens pointing to an Index page for the folder that contains the host page.
4b) with the project in localhost, clicking the filename link opens the host page as (program) in sources, but jumps to line 213

[Alexander Pavlov (apavlov)]

@Paul: you are using the "Support for SASS" experiment, right?

@Seva: can you comment on the bug once the resources start appearing for the *.scss files (per our offline discussion)?

[Alexander Pavlov (apavlov)]

(In reply to comment #0)
> 2) above a block of styles, view the filename
> 2a) Bug: it may appear as "css/..:213" which doesn't give the source filename

Could not reproduce this on tip of tree. I get "css/test.scss:213", which is ugly, of course, and I'm going to address this.

> 3) click the file link
> 
> 4a) on the file:/// protocol, a new tab opens pointing to an Index page for the folder that contains the host page.

Could not reproduce this either. With the experiment enabled, the Sources panel navigates to the correct line in the original scss.

> 4b) with the project in localhost, clicking the filename link opens the host page as (program) in sources, but jumps to line 213

Not sure what the correct behavior should be in this case, since the debug info generated by SASS provides absolute file://... URLs for the rules' original locations in scss files. This might or might not work at all.

[Alexander Pavlov (apavlov)]

Created attachment 169889 [details]
Patch

[Vsevolod Vlasov]

Comment on attachment 169889 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=169889&action=review

> Source/WebCore/inspector/front-end/CSSStyleModel.js:505
> +        if (!location.uiLocation())

Does it ever happen? We should avoid having rawLocation that does not have matching uiLocation as much as possible.

> Source/WebCore/inspector/front-end/CSSStyleModel.js:508
> +            this._locations = [];

nit: We will always have some live locations on CSSStyleModel, so I would move this._locations = []; to constructor (and annotate it) to make code simpler.

> Source/WebCore/inspector/front-end/Linkifier.js:113
> +    _updateCSSAnchor: function(anchor, uiLocation)

You should reuse _updateAnchor and move CSS domain specific logic to you own LinkifierFormatter implementation (probably inherited form DefaultFormatter).

[Alexander Pavlov (apavlov)]

Created attachment 170076 [details]
Patch

[Vsevolod Vlasov]

Comment on attachment 170076 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=170076&action=review

> Source/WebCore/inspector/front-end/CSSStyleModel.js:516
> +        if (!this._locations)

Redundant.

> Source/WebCore/inspector/front-end/CSSStyleModel.js:823
> +WebInspector.CSSRule.Location = function(rawLocation, updateDelegate)

Where is nothing rule specific here, let's call it WebInspector.CSSStyleModel.Location instead?

[Alexander Pavlov (apavlov)]

Committed r132197: <http://trac.webkit.org/changeset/132197>