Less.js: Wrong line-numbers on source-map selectors - chrome reports position of first element, not last element

Created on 14 Aug 2013  ·  5Comments  ·  Source: less/less.js

The following less would point into the line of html>body form although the definition was explicitly for input.
However, this would work correctly when using the & operator, but it is a pain to change all of the less definitions like that

html>body form  {

    input {
        color: cyan !important;
    }

    & input {
        background: yellow !important;
    }
}

line bug

I think this can be extent to other operators supported in less, but never the less, either empty or any operators should be supported correctly by the source maps, since it is valid less code.

bug medium priority

Most helpful comment

note: work-around from #1715 is to control and click on the property not the selector.
note 2: chrome won't fix it so it would have to be addressed in less, probably finding the last element index ? in a selector

All 5 comments

I think this is because less actually marks up different parts of the selectors coming from different places.. so it tells chrome the first part of the selector comes from line 3 and the second part from line 9. When less uses & it actually breaks the implementation and less only tells chrome about the 2nd part.

However given the information in chrome is very sketchy anyway, we should probably only show information from the last part of the selector.

this bug is now in the chromium bugs: https://code.google.com/p/chromium/issues/detail?id=287382

note to self: could be solved by overriding the fileinfo before each path is output. also need to think about extends where the middle selector is replaced - the path is created because of the extend so the extend is the important thing.

marking this low as now as you can always scroll down.. it at least gives you a pointer.. unless @dotnetwise you have a reason why this is causing a big problem.

note: work-around from #1715 is to control and click on the property not the selector.
note 2: chrome won't fix it so it would have to be addressed in less, probably finding the last element index ? in a selector

I have tested the example code from: http://stackoverflow.com/questions/27983598/css-source-maps-doesnt-report-the-correct-line-when-using-nested-selectors

#main {
max-width: 500px;
color: white;
.sub-container {
color: blue;
}
}

I found that the problem not only happens in chrome but also in firefox. Then i tried to compile the code with gulp-less and gulp-sourcemap (where i expect that gulp-sourcemap uses a different sourcemap generator ). The gulp build did not solve the problem too.
When i compile the same code with sass the generated sourcemap points correctly to 4 in both chrome and FF.

On the other hand Less has the correct line numbers at some point (with --line-numbers=comments):

/* line 1, /t.less */
#main {
  max-width: 500px;
  color: white;
}
/* line 4, /t.less */
#main .sub-container {
  color: blue;
}

Yes, but only for not "nested rules"

If you nest anything in a big rule, then all the sourcemap lines will point to its top.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

joe223 picture joe223  ·  4Comments

rejas picture rejas  ·  6Comments

xblakestone picture xblakestone  ·  3Comments

renoth picture renoth  ·  6Comments

Oskariok picture Oskariok  ·  6Comments