Where do you see 8a67263f2d4e0fcbf1675e08b7e24672046463d2 being used? I can see ec33cd0c06881d919ac0de419d829ad914e0be8f and it works.

It is used by DevTools when I view a .jsx file in the Sources tab. I'm attaching a screencast that shows the captured request in chrome://net-internals.

It's also in the file(s) mentioned in my opening message, whereas the working SHA1 isn't found anywhere in the Chromium 57.0.2987.133 release sources [1]:

----------------------------
$ grep -r ec33cd0c06881d919ac0de419d829ad914e0be8f 
$ grep -r 8a67263f2d4e0fcbf1675e08b7e24672046463d2
build/util/LASTCHANGE.blink:LASTCHANGE=8a67263f2d4e0fcbf1675e08b7e24672046463d2
build/util/LASTCHANGE:LASTCHANGE=8a67263f2d4e0fcbf1675e08b7e24672046463d2
----------------------------

Please let me know if I can provide any other useful information.

[1] https://commondatastorage.googleapis.com/chromium-browser-official/chromium-57.0.2987.133.tar.xz

Deleted: chromium-devtools.mp4 676 KB

	chromium-devtools.mp4 676 KB View Download

evangelos@ Could you please help us with the sample html file and the expected behavior for further triage.

Thank You...

I have uploaded a sample .jsx file here: https://foutrelis.com/cr710701.jsx (Had to self host it to make sure it's served as text/jsx.)

If you open up DevTools on the above URL and go to the Sources tab, you can view the .jsx file but it will not have any syntax highlighting. When you click to view the file in DevTools, Chromium makes the following request which returns 404:

https://chrome-devtools-frontend.appspot.com/serve_file/@282d60fedefa2a065674798acbf1af61c127c8b6/cm_modes/cm_modes_module.js

(Related errors are also printed to the terminal: https://foutrelis.com/cr710701-stderr.txt)

The SHA1 contained in the above request (282d60fedefa2a065674798acbf1af61c127c8b6) can be found in the Chromium 58.0.3029.81 source tarball:

$ grep -r 282d60fedefa2a065674798acbf1af61c127c8b6
src/chromium-58.0.3029.81/build/util/LASTCHANGE.blink:LASTCHANGE=282d60fedefa2a065674798acbf1af61c127c8b6
src/chromium-58.0.3029.81/build/util/LASTCHANGE:LASTCHANGE=282d60fedefa2a065674798acbf1af61c127c8b6

It corresponds to the release tag in the Git repo: https://chromium.googlesource.com/chromium/src.git/+/58.0.3029.81

As suspected, if I edit build/util/LASTCHANGE.blink and put in the SHA1 of the parent commit (ac0bae59f0aa5b391517e132bf172144b1939333), the problem goes away and syntax highlighting works for the .jsx file.

Possible fixes (in order of perceived correctness and feasibility):

1) Somehow make chrome-devtools-frontend.appspot.com recognize the SHA1 that is in Chromium source tarballs.
2) Adjust build/util/LASTCHANGE{,.blink} in Chromium source tarballs to contain a recognizable SHA1.

Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

chenwilliam@, M57 is already old, stable is now on M58, so this ticket is obsolete.  But perhaps you may know why the requested hash was not working?

Why was the issue marked WontFix? Comment 5 shows it's still an issue with Chromium 58, so how is it obsolete?

I don't think this should have been closed. Per comment 5, it still affects M58.

Pawel, can you help take a look and see if the tarball generation is putting the wrong values in build/util/LASTCHANGE* ? I imagine other distros that use the source tarball are affected as well.

Sorry everyone for closing this earlier.  I was too eager to jump when I saw the M57 in the original description.  This still affects people and warrants investigation, my bad.

This isn't specific to the tarball generation. Checking out the code from git also produces the same incorrect results :(

The problem is that when we publish the DEPS file for a particular buildbot build of Chrome, this creates a new commit (which is what the tag points to). Unfortunately, the uploaded devtools frontend files are based on the Chrome builds, which happen *before* the new commit with the release's DEPS file is created (since that happens as a result of the build, not as a trigger for it).

There's not an obvious non-hacky fix for this. You could have lastchange.py try to detect when the current commit is a DEPS publication (by checking if its author is chrome-release-bot@chromium.org and/or if the commit message is "Publish DEPS for Chromium \d.\d.\d.\d"), and if so, ignore that commit and instead return the parent commit? Kinda gross, but should work..

(alternatively we could try to fix the weird indirect way that Chrome internal builders track release branches that causes this extra DEPS-updating commit to exist in the first place.. but that's probably out of scope here) :)

Alternatively, we could just publish a duplicate copy of each devtools frontend at whatever the chromium DEPS commit hash ends up being. Not sure if that's practical (I'm not sure if the things that do those two tasks are actually near each other/directly related)

I wonder why are the files fetched remotely if they seem to be built locally?

~/dev/chromium/src/out/Default$ find . | grep cm_modes
./resources/inspector/cm_modes
./resources/inspector/cm_modes/cm_modes_module.js
./resources/inspector/cm_modes_module.js

Hm, that's a good question. When remote debugging (either from one chrome to another, or from desktop chrome to android chrome), they're fetched remotely because they need to be from the *target* chrome's exact version, but I don't think there's any reason to fetch them remotely when just using devtools to debug the current browser.

The issue with the git commit needs fixing even if there's another problem here, because it will still break remote debugging even if there's a better fix for local debugging.

Even for remote debugging, would it make sense for the remote browser to have its own resources locally, and when needed the resources could then be fetched from remote browser (having them locally), as opposed to remote server. Does that make sense?

Maybe? I don't really know much about why it's this way, I just recalled the version lookup mechanism from when we originally got this working in WebView.

A related bug, semi-duplicate.

https://bugs.chromium.org/p/chromium/issues/detail?id=742993

Another, closed bug.

https://bugs.chromium.org/p/chromium/issues/detail?id=746600

I think this (new) problem should be documented on https://www.chromium.org somewhere, perhaps in the build instructions. I ran into it with Lighthouse, but also with Developer Tools on Android.

I can't try right now, but if I understand #11 correctly, then only 675d104ab3941d0a73080bec36f737016cbc124b from the following commits will have https://chrome-devtools-frontend.appspot.com not return 404. I'm unsure about e61cc3cb8e6a9efae69dbf02c5b67d4ddfc5db3f as it's also bot-authored.

https://chromium.googlesource.com/chromium/src/+log/60.0.3112.80..60.0.3112.81?pretty=fuller

If so, there doesn't seem to be an easy way to get such a commit in an automated way, using the JSON version information published on OmahaProxy.

@pfeldman, just re-forwarded you the email chain for context.

To answer my question: just rewinding by 1 commit works. It doesn't matter who the author is.

Some explanation as to why this won't be fixed would be nice.

This is still a bug.  Reopening.

pfeldman@: Could you forward me the email chain for context?  You could reassign to me if you think this is better fixed src-side.  We could always add the hack from c#11

 Issue 732992  has been merged into this issue.

This appears to be fixed in Chromium 67 by  https://crbug.com/760304#c11 .

You can probably go ahead and close this as a duplicate of  issue 760304 .

Yup, that should resolve this about as well as it can. I have a followup suggestion to slightly improve it I'll make on the other bug.