New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 665781 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Last visit 29 days ago
Closed: Feb 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

DevTools: Workspace mapping autocomplete broken in Canary

Reported by teo.eter...@gmail.com, Nov 16 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2920.0 Safari/537.36

Steps to reproduce the problem:
Perform a workspace mapping in setting on Canary and Stable.
1. Add workspace folder on both browsers - the folder appears in the settings
2. Perform a "map to filesystem resource..." from the source tree on both browsers
3. The workspace in canary is not mapped correctly

What is the expected behavior?
the WebURL should not be shown only the system path, in canary both are shown like its not mapped.

What went wrong?
After performing "map to filesystem resource..." :

Stable
http://prnt.sc/d7wt6l

Canary
http://prnt.sc/d7wt15

The same problem is visible in the quick file search:
Stable
http://prnt.sc/d7wtb6

Canary
http://prnt.sc/d7wtg7

Did this work before? Yes Version 54.0.2840.98 (64-bit) MacOS

Chrome version: 56.0.2920.0  Channel: canary
OS Version: OS X 10.12.1
Flash Version: Shockwave Flash 24.0 r0
 
ps. i forgot the say that the mapping works, when i change something in the sources it's also changed in the filesystem file
Also a subBug, only the 127.0.0.1/network version is found not the local drive version
http://prnt.sc/d7x3f7

Comment 3 by l...@chromium.org, Nov 16 2016

Labels: Needs-Feedback
Owner: lushnikov@chromium.org
Status: Assigned (was: Unconfirmed)
Thank you for the report.  I'm not able to reproduce seeing the 'source' folder in my test.

@OP: could you please share with us a screenshot of the Workspace settings screen that shows your mappings?  That could help us understand the directory structure and try to reproduce this behavior.

@lushnikov, could you please take a look?  From the 2nd screenshot, it looks like Persistence is not enabled in the user's canary.
https://www.youtube.com/watch?v=G6gaE0VxyUI

you can see it in the video. ps. I'm runnging chrome with
open  -a  /Applications/Google\ Chrome\ Canary.app -F -n --args --allow-running-insecure-content --disable-web-security --user-data-dir

but that shouldn't be a problem.

The binding actually works, when I edit the files they are changed on desktop. it
's just the file search function and the tree that displays wrong results.

ps. there is another small problem the chrome menu dots are missing in canary
https://youtu.be/G6gaE0VxyUI?t=29

You can see that i can;t find them so i use the window menu to navigate to About

Hi Teo, thank you for the bugreport. It looks like we report you the network name of the UISourceCode instead of filesystem uiSourceCode. We'll change this.

While we're here, we have a "persistence2.0" experiment which introduces automapping. Could you please give it a shot and tell us what doesn't work?
I'm using persistence 2.0 now latest Canary
https://www.youtube.com/watch?v=B3mFK18Vp_Y

that could be a related issue to both. Eiter it's a new bug or it's bound to persistence 2.0

when opening a document directly from source it's not sourcemapped 
Ok, so it's a lot going on here.

Original bugreport: got fixed by https://codereview.chromium.org/2551233002/.
Comment #4: as far as I understand this is the recording of the bug report - so it's fixed.
Comment #6: again, got fixed by the CL.

Let me know if I missed something of if something is still not working for you!



Status: Fixed (was: Assigned)

Sign in to add a comment