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

[dotnetwise]

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;
    }
}

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.

[lukeapage]

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.

[lukeapage]

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.

[lukeapage]

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

[bassjobsen]

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;
}

[dotnetwise]

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.

[mariusGundersen]

I've had a look at this with a simple less file:

.top {
  color: red;

  .first {
    color: blue;
  }

  & .second {
    color: green
  }
}

which produces this css file

.top {
  color: red;
}
.top .first {
  color: blue;
}
.top .second {
  color: green;
}

and the sourcemaps:

{
  "version": 3,
  "sources": [
    "style.less"
  ],
  "names": [],
  "mappings": "AAAA;EACE,UAAA;;AADF,IAGE;EACE,WAAA;;AAGF,IAAE;EACA,YAAA"
}

Looking into it the problem is that line 4 and line 7 in the css file are slightly different:

less ->  css
1 0  ->  4 0
4 2  ->  4 4
8 2  ->  7 0
8 4  ->  7 4

In line 4 of the css (.top .first {) the .top maps to line 1 column 0 of less (.top {)
In line 7 of the css (.top .second {) the .top maps to line 8 column 2 of the less ( & .second {)

So by using the & character the outer selector is mapped to the right place. So the workaround is a bit of a strange hack, in my opinion. I would exect clicking on .top in both lines of css to take me to the same place, but it doesn't. That is, it should be even more wrong, in my opinion, as neither of these should work.