[CLOSED] Fix for launching Chrome with temporary profile in OSX. #217
Comments
|
@fungl164 Thanks for submitting this pull request! You'll need to agree to the Brackets CLA before I can merge this. |
|
@fungl164 This doesn't seem to work how I was expecting it to. On Windows, you can open a Chrome browser window and have some Tabs open in that window. Then in Brackets, when you start Live Development, it opens a second Chrome browser window. On MacOS 10.8, Live Dev tries to open a new Tab in existing window, fails, and then prompts me to Relaunch Chrome. With this code, can you open Live Dev in the scenario above without getting the Relaunch Chrome prompt? If so, is Live Dev opened in a new window, or just a new Tab? |
|
@fungl164 I've been playing around with this and I can get it to work when I type in the args on the command line, but not in Brackets, so I guess it must have something to do with how the command is getting built in brackets-shell. If you get a chance to work on this some more, we want the user data dir to go the app support folder, and use a different name to be consistent with other platforms, which needs to be quoted since there are spaces in the path, so something like: And one other flag for those that have a default browser other than Chrome: |
|
@redmunds so I made a few changes to make chrome startup and terminate based on proper process ids (fungl164@8e0fa25). I've also added your comments as a separate commit (fungl164@44b8b79). I still cannot get Brackets to issue a CloseLiveBrowser() call when clicking on the Live Dev icon. I believe its somewhere in the js code, but I don't know the proper place to put it. Once that's done, it should terminate correctly. Disabling Live Dev from the toolbar just closes the tab but leaves the chrome instance running right now because of the missing call to CloseLiveBrowser(). To enable Live Dev, you'll need to close the second instance of Chrome and click the icon in Brackets. |
|
amended last commit to account for common profile path in process id look-up. |
|
Awesome! This is getting very close. It's not critical that Chrome app stays open with no windows open because that's how it behaves now, but yes it would be nice. If you want to mess with it, the next function in the brackets-shell code is The main problem I am seeing is that a Tab with the "interstitial" page (LiveDevelopment/launch.html) is staying open on the first launch. If no Chrome window is open, then the tab is in the live-dev-profile window. If there is already a default Chrome window open, then the Tab is in the default window. Any ideas on that? |
|
Also, is |
|
@redmunds added fix for brackets source to call native impl of CloseLiveBrowser(). |
|
Found a bug:
Results |
|
also make sure you have the modifications I made to brackets |
|
No, I did not see the change you made to the brackets repo. Please submit a pull request so I can test & then merge both pull requests together. Thanks. |
|
Done. |
|
The brackets repo change fixes the bug I reported above. Unfortunately, I am seeing some of the tests fail. Here's how to run them:
|
|
Mine passes. Which tests are failing for you? |
|
Just 1 test is consistently failing at the moment: |
|
I found another bug:
Results: Expected: |
|
Well, that is expected. What's happening is that a call to Native.closeLiveBrowser() will terminate the browser session completely (including all tabs and windows) by terminating the process. What you're expecting is probably better handled in the JS code (e.g. close a tab), rather than requesting the native code to close down the live-dev browser session. Note there is a side effect of just closing a tab. It means that the browser will remain in debug mode with and open port until closed (which could be construed as a security issue). Being that it is also working off a separate profile...the end user cannot and should not expect to have the browser state to be in sync with the non-debug enabled user profile. Do you agree? |
|
I discussed this with @gruehle before I logged it here, and we both thought Brackets closing what seem like unrelated browser tabs/windows is worse. Part of the problem is that there doesn't seem to be a way via the Chrome UI to open a new tab or window using the default Chrome profile. I'll see what the rest of the team thinks, but I would not expect Brackets to close something that it didn't open. |
|
Perhaps one of the flags that hides the ability to create new tabs (e.g. appmode) could act as a hacky workaround? This may also make it clearer that the Chrome window is related to brackets. |
|
@MattSturgeon Thanks for joining the conversation! The only reason that I opened new tabs/windows in the live-dev-profile is because I couldn't figure out how to open them in the default profile -- which I think would be the usual intent. Is there any way to do that? Maybe it's caused by one of the flags we're using? If disabling the ability to open tabs/windows using the live-dev-profile causes new windows to get opened in the default profile, then I think that's perfect. Another thing we should do (but not required for this pull request) would be to create a custom skin for live-dev-profile to make it obvious that it's a window created by Brackets and you don't want to be creating new tabs/windows in it. |
|
@redmunds I was thinking along the same lines of skinning. I'm all in favor of keeping things separate. It is the main reason for me getting the shell to behave this way. I don't want Live Dev to mess around with my normal browsing session. I can alter the live-dev profile to my liking without consequences. Otherwise things start to get whacky and hacky. :) |
|
I had hoped that running with |
|
Also, note that the LiveBrowser session I'm creating is a completely separate instance of Chrome that runs concurrently. This means not relaunching and not restoring the previous 1000+ windows/tabs I often have open during normal browsing for the sake of turn on the debug port. That's the beauty of separation... :) |
|
How does enabling remote debugging work on windows? |
|
All good questions. I haven't used windows in a couple of years, but I highly doubt it happens retrospectively. |
Thursday Sep 26, 2013 at 20:59 GMT
Originally opened as adobe#339
Prevents Brackets from interfering with end-user sessions in Chrome (i.e. history, open tabs, etc.).
See related: adobe/brackets#2998.
This requires brackets pull request: adobe/brackets#5392
fungl164 included the following code: https://github.com/adobe/brackets-shell/pull/339/commits
The text was updated successfully, but these errors were encountered: