Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
dotnetwise opened this issue Aug 14, 2013 · 7 comments

Comments

@dotnetwise
Copy link

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.

@lukeapage
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Author

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.

JianJiao added a commit to JianJiao/portfolio that referenced this issue Sep 14, 2015
* sourceMap pointing to wrong file at times
* don't know if this is issue with grunt-contrib-less, or the config
* related links: less/less.js#1492,
gruntjs/grunt-contrib-less#243 (comment)
* possible: nested selector, import; or configuration is not right. But it
  works for some css rules, breaks for others. Weird.
@mariusGundersen
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants