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

Issue 376788 link

Starred by 55 users

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature



Sign in to add a comment

DevTools: devtools settings are ignored/reset in Incognito mode

Reported by nch...@gmail.com, May 23 2014

Issue description

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

Steps to reproduce the problem:
1. Open Developer tools for a normal chrome tab/window. Undock the Developer Tools.
2. Open a new window/tab. Open Developer Tools, note that the new Developer Tools instance is undocked. 
3. Open an incognito window, open Developer Tools, note that Developer Tools are docked. 

What is the expected behavior?
Incognito window Developer Tools should remember the docked/undocked state of normal windows. OR, a user should be able to choose a preference for docked/undocked developer tools that will be used as the default when a new Dev Tools instance is started.

What went wrong?
Developer Tools docked/undocked state did not persist into Incognito session. If it cannot "know" the state of the original window I think that's fine assuming we can choose a preference that the Incognito window will default to.

Did this work before? Yes I don't know the version of Chrome where this worked, but I think it worked about a month ago.

Chrome version: 34.0.1847.137  Channel: stable
OS Version: OS X 10.9.2
Flash Version: Shockwave Flash 13.0 r0
 
Owner: dgozman@chromium.org
Status: Assigned
Status: WontFix
Incognito tab is incognito, and DevTools preferences should not cross incognito border.
The dock/undock setting used to be shared between normal/incognito unlike all the other settings, but we have unified them.
It gets quite annoying resetting the options every time. Undock, disable cache while open, disable source maps, enable xmlhttprequest logging.

If you won't let it use the non-incognito settings like it used to, how about adding in preferences that we can change specifically for incognito?
Labels: -Pri-2 -Type-Bug -OS-Mac Pri-3 Type-Feature OS-All
Status: Assigned
Summary: DevTools: Feature request to save preferences set in inspector for incognito window (was: Incognito Developer Tools Do Not "Remember" Docked/Undocked State)
Another solution is to use a separate profile to develop in. Another user profile would save your devtool settings that you set in it while not letting extensions and such interfere. The only other thing it would do incognito doesn't is save a bit of history, but that shouldn't be a big deal in development.

Is there some reason incognito is particularly superior to a separate development profile?

Comment 6 by loislo@chromium.org, Oct 22 2014

 Issue 425592  has been merged into this issue.

Comment 7 by pdk...@gmail.com, Nov 19 2014

duplicate: https://code.google.com/p/chromium/issues/detail?id=171335

And yes, making it docked by default is a terrible decision. I guess MTV got a delivery of 21:9 screens recently.

Comment 8 by rob@robwu.nl, Dec 11 2014

Blocking: chromium:441474
 Issue 441474  has been merged into this issue.
Blocking: -chromium:441474
jonathan: "Is there some reason incognito is particularly superior to a separate development profile?"

There are a few reasons:

1. I disabled profile button as soon as it came out because I was the only one who is using my laptop. (Instructions on how to do that: http://lifehacker.com/how-to-disable-chromes-new-user-menu-1679224275)

2. Profile button takes a space of one tab. I changed it's name to a single character to reduce its size.

3. My face appears on the chrome icon. I removed that by uploading transparent PNG as my avatar. I also selected the "Slender man" avatar for my "incognito" profile. I was going to upload my own image, but that requites hacks (Instructions: http://superuser.com/questions/449244/how-do-i-access-edit-the-chrome-user-avatar-images)

4. Instead of one short cut CTRL-SHIFT-N I have to make 3 clicks.


Non of them seem fatal, so I'll try dev profile.
I prefer incognito over creating a Dev profile because it's easier to wipe out session data which I'm constantly doing for testing and development work (especially for signup/login/logout work). All you have to do is close and re-open the incognito window.
Status: WontFix
This is not an easy thing to do, not worth it.
Seems like a lot of things in Chrome aren't worth fixing these days.
We can't violate the core incognito principles: can't persist settings, can't create traces of the activity so to speak.

I'd suggest that you give suggestion #5 a try.
I think it is totally fine to keep the core incognito principles and mark this ticket as won't fix.  I think the reason this ticket picked up a lot of traction to begin with was because of you guys changing the default behavior of the dev tools.

Personally, it drives me crazy that the dev tools now open on the right side when I open a new incognito window (https://code.google.com/p/chromium/issues/detail?id=408242).  I can understand this makes some sense on laptops with limited vertical space, but even there I prefer it on the bottom.

It is an extra step and extremely annoying for me to have to move the inspector to the bottom every time that I need to use it on an incognito window.
> #15 pfeld...@chromium.org
> We can't violate the core incognito principles: can't persist settings, can't 
> create traces of the activity so to speak.

I don't agree that the setting for the developer tools is a "trace of activity".
And even if you say so, the same should apply to the extensions - which you can clearly mark as "allow in incognito". 

Comment 18 Deleted

Comment 19 by jul...@ladbury.biz, Feb 25 2015

Re closing comment #13:
'This is not an easy thing to do' - should not be a consideration
'Not worth it' - the discussion mentioned in comment #16 suggests it would be worth it to several people. Count me among them. 

Comment 20 by jsp...@gmail.com, Feb 25 2015

I'm disappointed to see this issue closed as Won't Fix. The change in the default location for the dev tools is what caused me to seek out and follow this issue in the first place. It really threw a monkey wrench in my workflow.

Using a dev profile isn't a great option. Yes, it lets me put the dev tools in the preferred spot, but now I have to clear browser history frequently. I'm trading one set of extra steps for another. Before the change, I just had to hit Ctrl-Shift-N and I've got a new window with a fresh history instantly.

A preferences setting for dev tools location is too hard? Really? ...Really?

Comment 21 by to...@tweek.us, Feb 25 2015

> We can't violate the core incognito principles: can't persist settings, can't create traces of the activity so to speak.

Open incognito window, open DevTools, Undock, Resize and reposition DevToos, Close out incognito, Reopen incognito and DevTools, Undock.  You will find that the undocked DevTools remembers the size and position.  Why can't the docked version behave the same?

I can understand the reasoning behind having it defaulted to the right on wider screens, but it still must be resized to make it usable.  I mean, have any of you actually looked at it at the docked default size?  The element inspector is too dense, and a lot of the other tools just aren't useable without resizing or moving it.

Using a separate development profile would be fine if I could actually create a _development_ profile.  One that resets all website data when the profile is started with no existing windows.  But, having an option so that the DevTools inherit its parent profile's position and size seems like it would be easier for everyone.
Screen Shot 2015-02-25 at 9.36.01 AM.png
60.4 KB View Download
Screen Shot 2015-02-25 at 9.35.24 AM.png
85.3 KB View Download
Screen Shot 2015-02-25 at 9.37.08 AM.png
55.2 KB View Download
Screen Shot 2015-02-25 at 9.36.48 AM.png
42.4 KB View Download
Screen Shot 2015-02-25 at 9.36.24 AM.png
39.3 KB View Download
Tommy,  Issue 433117  is open about widening the default layout. So once that is resolved it won't be squished.

On the point of undocked being remembered, that is *most likely* the operating system remembering the window position on its own. DevTools doesn't control undocked window placement, the OS does.


dgozman, pfeldman:

Can we please reconsider fixing this? This bug was brought to my attention because bug 461512 is a suggested workaround, but it's an unacceptable solution and dangerous if it becomes common practice.

The argument that this is incognito mode, and therefore settings shouldn't persist, is not applicable here. We're talking about devtools - browser UI - not cookies set by websites. Incognito mode is for cookies.

I'd argue that not only should docking settings in incognito be read from the normal profile, they should even be written back.

As a data point, we persist bookmarks added in incognito (with the old bookmark system - the new, based on an extension, appears to have a bug). We also share extensions in incognito mode if the user opts into that - and opening devtools on a page *is* opting in.
@kal thank you!  I strongly agree with you about your suggested behavior being better (including writing back your preference).  

Right now it just feels broken that your developer tools are set to open one way, but then if you open an incognito window they show up in a completely different place and there is no way to get it to stick.  If you had a shared extension and your extension didn't remember your settings in incognito, everyone would think it was a bug.
To add some context here for people, all of devtools preferences are stored in localstorage. You can see that by inspecting the inspector: http://i.imgur.com/VjK6cH1.png

Allowing access to the localstorage from an incognito window means ferrying this data cross-process. This is not trivial, and has implications on security in addition to the raw implementation effort.


@Tommy, 
yeah the default size was busted. Sorry about that. We fixed it via  Issue 433117  so now you can see in Canary incognito it's not so squeezed any longer.

@ kalman
> I'd argue that not only should docking settings in incognito be read from the normal profile, they should even be written back.
Disagree. Incognito feels very disposable as a user. I can see settings being persisted back, but it also would be completely reasonable for it to not.


If we move forward with this, I would expect to clone the original devtools settings, drop them into the incognito devtools, and never save them back. This would also be a much more manageable implementation.

That said, this is a significant effort and it's hard to prioritize against our other goals.
Summary: DevTools: devtools settings are ignored/reset in Incognito mode (was: DevTools: Feature request to save preferences set in inspector for incognito window)
This issue is the same as  Issue 171335 . I'm updating the description here to clarify the goal.
Cc: ashej...@chromium.org
 Issue 171335  has been merged into this issue.
I can see that if you use localStorage, and devtools runs in that incognito context, then yes this is an impossible situation. Extensions automatically route IPCs to the right place (cross incognito when appropriate), which is what I'm used to.

I am curious about this specific docking setting. Running undocked seems like it would require browser cooperation to do so (for creating a window - and IIRC you still do that), implying that this setting is stored on the browser side somewhere?

Therefore - and because I personally find the resetting of the windowing mode to be quite jarring - it would be nice to fix that. In my webdev days I used incognito a lot to test with a fresh set of cookies.

On the other hand, if I were a devtools, perhaps I'd also miss all of the other thing that would reset. But at least I'd have my window (or lack thereof).
> I'm updating the description here to clarify the goal

Actually, my goal is to just preserve the docking behavior, because that is the most jarring. Preserving *all* settings does sound quite hard. Most of the comments on this bug were about the docking, but you're right that comments like #3 are of a larger scope.

Looping back on myself, the workaround I mentioned in bug 461512 is to fix it all, so consider this no longer the voice of a security concerned extensions engineer, but rather of a puzzled user.

Comment 30 by rob@robwu.nl, Feb 26 2015

Synchronizing DOM storage between profiles seems hard (as far as I can tell, there is no straightforward way to get the StorageArea from a different profile), so how about an option to persist settings to Preferences (e.g. settings -> Advanced -> Click export)?

Then upon load of the devtools, when localStorage.length === 0, JS synchronously calls a method to initialize storage using the previously saved prefs. Implementing this concept seems straightforward, any objections?
@kal, @paulir,

Many thanks for your concern. Can you please persuade your fellow chromium devs to reconsider and open this one up again?

+1 for @kal's suggestion in comment #29, as far as I'm concerned that suffices: remembering devtools position when docked, and whether it's docked or not.

Comment 32 by to...@tweek.us, Feb 26 2015

Thanks for the replies to my comment.  I wasn't aware the DevTools settings were stored in localStorage and can now appreciate how difficult persisting those settings into incognito might be.

This issue got me thinking that having a development profile that acted like incognito would be better than using incognito itself.  So, I created an unlisted extension that helps with that.  It clears data that you choose when there are no more tabs open in a profile.  I hope that those of you who are concerned with this issue finds it almost as useful as incognito mode.  If you have comments on it, please post a review on the extension page so this issue isn't derailed.

You can find the extension here: https://chrome.google.com/webstore/detail/developer-profile/pkpngjjbafobelnengjofedebcoofmff
@to..
Thank you, it solved my problems. 
Although it doesn't clear everything after closing (I suppose chrome running in the background is stoping it form cleaning), but the button is even better. I don't need to restart the window all the time

I created a devnull profile using this instructions: https://developer.chrome.com/devtools/docs/clean-testing-environment#gc-pagecontent

Comment 34 by to...@tweek.us, Feb 26 2015

@Datkowsk - There's a 500ms delay when the last window is closed since the onRemoved event fires for each tab that's closed (if you're closing an entire window).  I suspect that you're exiting Chrome instead of just closing windows, which won't give the background script enough time to clear the data before its unloaded.  I uploaded a new version that clears data on startup if it was unable to clear the data on all windows closing, but it'll take about an hour before it's available.  In hindsight, I should be using window events instead of tab events and will change that when I have more free time.  If you have any other other problems with it, please create an issue on my repo: https://github.com/tweekmonster/Developer-Profile
Please fix this asap. As QA's we open and close the incongnito windows constantly and having to redock the dev tools every time is HELLA annoying.
@cominotti, You should be using a separate profile for QA work. Comment #5 covers this and #32 has a link to a useful extension for wiping a specific profile's data on close.
A separate profile requires maintaining two full sets of extensions, and so isn't really an actual solution to the issue for most people. AFAIK, it's also not something you can trigger with a simple hotkey like you can an incognito session. Additionally, a big part of the incognito session that I appreciate is that it seems to base its starting history state on the parent profile -- so when I start typing in a website that I commonly visit on my standard profile, the incognito session knows to prefill the rest for me. None of which are addressed by using a separate profile.

Add me to the list of people who would love to see an actual fix for the issue in question -- that the dev tools either be docked to bottom by default, that there be some way of altering the "default value" from which incognito sessions derive their preference, or that the dev tools persist its position in some way that doesn't get lost on incognito session ending. As others have mentioned, it would be far from the first thing in the browser to behave this way (extensions being the most obvious), and would be opt-in (as opening dev tools is opting in).

Comment 38 by to...@tweek.us, Apr 3 2015

@chrisjoh... I used to feel the same way until I gave the secondary profile a chance.  It was convenient to have extensions share the same settings in incognito, but I rationalized that I would just have to set it up once in a separate profile if I needed one to exist in both.  It's not a huge inconvenience in hindsight.  On the positive side, the main profile I use for personal browsing now only uses extensions that are convenient for personal use and won't interfere with development (like adblocking).  My developer profile only has extensions for development such as rulers, javascript toggling, jQuery injection, and of course, Developer Profile ;)

I also was annoyed about the History thing, but I honestly don't miss it.  With the extension I made, you can set it to keep your browsing history, which helps autocomplete only the sites I've been working on, as well as only showing those sites on the new tab page.  I found this useful since it wasn't offering history completions for a million other sites that had nothing to do with my work.  Not to mention, I can have a separate set of bookmarks for reference material and local/test sites.

As for the keyboard shortcut, I'm using OS X, so I was able to set a shortcut for chrome like so: http://cl.ly/image/343N1P0H0Q1K  If you're on Windows, I'm not sure what an alternative to that would be.  Maybe AutoHotKey?
 Issue 472522  has been merged into this issue.

Comment 40 Deleted

Your points are not off-base, but ultimately they're all just workarounds to make another workaround less annoying. Workarounds on top of workarounds just to solve something that could be added as a flag is not ideal. And those points are just the ones that I came up with off the top of my head -- I'm sure over time I will find more quirks that make it more and more divergent and hard to maintain. I'd just rather not even go down that route, I do it often enough to know to avoid it. Inevitably trying to maintain two things to mimic each other leads to problems and headache.

If I'm going that far to work around the misbehavior, I'm just going to keep clicking the button to move it to the bottom every time I open an incognito window, since it's effectively six of one half dozen of the other. But my hope is that over time the browser will be able to fix this misbehavior instead of requiring me to use a solution outside of the browser to make the hack fit. I don't think it's unreasonable -- even if it's as simple as a flag to alter the "default".

As mentioned in another issue, I don't even know if I believe that moving it to the right by default was best for the majority of users. It seems more likely that some developers got larger screens and noticed it was annoying for them and decided to change the default. It isn't even usable on most screens the way it is now.

It's a little snarky, but this comment isn't totally off-base: https://code.google.com/p/chromium/issues/detail?id=408242#c13

Conveniently nobody responded to the point though...

Comment 42 by j...@proto3.com, Apr 3 2015

I am probably part of the silent majority here, I never have participated in these issues' discussions. It is annoying enough for me that I am now.  I have a large monitor, but I split my screen with browser on left and editor on right.  I am constantly having to do the dance to move toolbar to bottom.  

I don't have any problem with the default being changed, but as many have said, please just a flag/option to change it.  

It is annoying enough that I have been trying firefox for dev work.

All these words basically to say one +1 vote for changing this somehow.
Cc: dgozman@chromium.org
 Issue 470560  has been merged into this issue.
Cc: pfeldman@chromium.org
 Issue 413043  has been merged into this issue.
Cc: -pfeldman@chromium.org paulir...@chromium.org
Labels: -Pri-3 Pri-2
Owner: pfeldman@chromium.org
Status: Assigned
Hi folks, thanks for coming here and sharing your feedback.  
Also big thanks to Tommy for the useful Developer Profile chrome extension: https://github.com/tweekmonster/Developer-Profile


There are a few tickets circling around this topic, and I've just duped them into this grand-daddy one.

We're very aware that incognito is a very critical feature for developers and recognize the current non-persistence of devtools settings makes it annoying to use.
We would like to solve this issue for most people. I think it can be done.


Docking and appearance settings
====================

Docking position and sizing is the most important aspect of the feedback we've heard before. We were thinking of special-casing docking and persisting that into incognito.  


All DevTools settings
=============

A few tickets have offered other settings that are important to persist. E.g.  disable cache, disable source maps, enable xmlhttprequest logging in console.  I know disable cache is a big one for me. Console history would be nice. 


Incognito as Sanity check
===============

When things are going crazy, we pop into incognito to make sure its not a chrome extension or whatever messing with the page.  As such, we do expect it to be somewhat fresh and clean.  But when we persist settings, we conflict with the expectation that it's Chrome in its default, normal behavior.
So we think not 100% of devtools settings should be persisted.


The plan
======

* Bookmarks in Chrome persist inside of incognito. They inherit the foremost window's profile. This model makes sense.
* We are going to adopt the same policy for DevTools. When you launch incognito, we'll use the devtools settings from the foremost window. 
   * We will blacklist carrying over a few select settings. Currently, the blacklist looks like this:  workspaces, breakpoints, DOM breakpoints. 
* Changes to devtools settings while in incognito will be persisted back to the original profiles devtools settings.
* Creating a new profile will be the best solution for pure isolation, including fresh DevTools settings.


I don't think this will satisfy everyone, but hopefully it will be more enjoyable than current behavior. Cheers.
Cc: jonathan.garbee@chromium.org

Comment 47 by pdk...@gmail.com, Apr 5 2015

> When you launch incognito, we'll use the devtools settings from the foremost window. 

I think there is an opportunity here for a simple way to launch a truly fresh incognito window: make incognito windows not inherit from other incognito windows. So you just need to press Ctrl+Shift+N twice to get such a window. With perhaps a small message in console stating so, or a small icon indicating this.

Of course it's not a perfect solution, because you now also have a useless (first) incognito window.

Comment 48 by geki...@gmail.com, Apr 7 2015

I think the Incognito concept is inconsitent. Save every interface settig or save complete nothing.

If you change the name of Incognito you could make a window that saves everything (also allow fullscreen settings) except browser history, cache, cookies
AND the Guest Profile could be the "Incognito" one
Project Member

Comment 49 by bugdroid1@chromium.org, Apr 14 2015

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6672e7d32a24d2f35d6decd9f3cd2a8285c16f6c

commit 6672e7d32a24d2f35d6decd9f3cd2a8285c16f6c
Author: pfeldman <pfeldman@chromium.org>
Date: Tue Apr 14 10:08:58 2015

DevTools: allow storing devtools preferences on the browser side.

BUG= 376788 

Review URL: https://codereview.chromium.org/1079843002

Cr-Commit-Position: refs/heads/master@{#325019}

[modify] http://crrev.com/6672e7d32a24d2f35d6decd9f3cd2a8285c16f6c/chrome/browser/devtools/devtools_embedder_message_dispatcher.cc
[modify] http://crrev.com/6672e7d32a24d2f35d6decd9f3cd2a8285c16f6c/chrome/browser/devtools/devtools_embedder_message_dispatcher.h
[modify] http://crrev.com/6672e7d32a24d2f35d6decd9f3cd2a8285c16f6c/chrome/browser/devtools/devtools_ui_bindings.cc
[modify] http://crrev.com/6672e7d32a24d2f35d6decd9f3cd2a8285c16f6c/chrome/browser/devtools/devtools_ui_bindings.h
[modify] http://crrev.com/6672e7d32a24d2f35d6decd9f3cd2a8285c16f6c/chrome/browser/devtools/devtools_window.cc
[modify] http://crrev.com/6672e7d32a24d2f35d6decd9f3cd2a8285c16f6c/chrome/common/pref_names.cc
[modify] http://crrev.com/6672e7d32a24d2f35d6decd9f3cd2a8285c16f6c/chrome/common/pref_names.h
[modify] http://crrev.com/6672e7d32a24d2f35d6decd9f3cd2a8285c16f6c/content/shell/browser/layout_test/layout_test_devtools_frontend.cc
[modify] http://crrev.com/6672e7d32a24d2f35d6decd9f3cd2a8285c16f6c/content/shell/browser/shell_devtools_frontend.cc
[modify] http://crrev.com/6672e7d32a24d2f35d6decd9f3cd2a8285c16f6c/content/shell/browser/shell_devtools_frontend.h
[modify] http://crrev.com/6672e7d32a24d2f35d6decd9f3cd2a8285c16f6c/content/shell/renderer/test_runner/test_interfaces.cc

Project Member

Comment 50 by bugdroid1@chromium.org, Apr 14 2015

The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=193715

------------------------------------------------------------------
r193715 | pfeldman@chromium.org | 2015-04-14T16:52:04.355193Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/SourcesView.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/ui/SplitView.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/components/DOMBreakpointsSidebarPane.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/main/Main.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/workspace/FileManager.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/AdvancedSearchView.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/EventListenerBreakpointsSidebarPane.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/TabbedEditorContainer.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/host/InspectorFrontendHost.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/workspace/ExcludedFolderManager.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/Runtime.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/XHRBreakpointsSidebarPane.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/inspector/split-view.html?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/devtools_app/InspectorFrontendHostImpl.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/bindings/BreakpointManager.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/SourcesPanel.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/common/Settings.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/WatchExpressionsSidebarPane.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/inspector/inspector-test.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/workspace/FileSystemMapping.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/inspector/split-view-expected.txt?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/console/ConsoleView.js?r1=193715&r2=193714&pathrev=193715
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/settings/SettingsScreen.js?r1=193715&r2=193714&pathrev=193715

DevTools: allow storing devtools preferences on the browser side. [blink]

BUG= 376788 

Review URL: https://codereview.chromium.org/1066813003
-----------------------------------------------------------------
Status: Fixed
Great! When should we expect this in public version?

Comment 53 by rob@robwu.nl, Apr 15 2015

Labels: M-44
#52 The feature is available from 44.0.2370.0 onwards. The latest Canary version includes this feature, and in approximately 6 weeks it will also be in Beta. After another 6 weeks, it will finally become available to everyone on the stable channel.

(if you want to have the feature as soon as possible, consider switching to a different release channel: https://www.chromium.org/getting-involved/dev-channel)
Project Member

Comment 54 by bugdroid1@chromium.org, Apr 15 2015

The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=193772

------------------------------------------------------------------
r193772 | mlamouri@chromium.org | 2015-04-15T09:59:21.858268Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/inspector/inspector-test.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/workspace/FileSystemMapping.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/inspector/split-view-expected.txt?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/console/ConsoleView.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/settings/SettingsScreen.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/SourcesView.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/ui/SplitView.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/components/DOMBreakpointsSidebarPane.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/main/Main.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/workspace/FileManager.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/AdvancedSearchView.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/EventListenerBreakpointsSidebarPane.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/TabbedEditorContainer.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/host/InspectorFrontendHost.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/workspace/ExcludedFolderManager.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/Runtime.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/XHRBreakpointsSidebarPane.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/inspector/split-view.html?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/devtools_app/InspectorFrontendHostImpl.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/bindings/BreakpointManager.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/SourcesPanel.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/common/Settings.js?r1=193772&r2=193771&pathrev=193772
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/WatchExpressionsSidebarPane.js?r1=193772&r2=193771&pathrev=193772

Revert of DevTools: allow storing devtools preferences on the browser side. [blink] (patchset #6 id:100001 of https://codereview.chromium.org/1066813003/)

Reason for revert:
This seems to have badly broken http/tests/inspector/service-workers/service-workers-redundant.html

See:
http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Oilpan%20(dbg)/builds/535

BUG= 472488 

Original issue's description:
> DevTools: allow storing devtools preferences on the browser side. [blink]
> 
> BUG= 376788 
> 
> Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=193715

TBR=dgozman@chromium.org,pfeldman@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 376788 

Review URL: https://codereview.chromium.org/1088093002
-----------------------------------------------------------------
Project Member

Comment 55 by bugdroid1@chromium.org, Apr 15 2015

The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=193779

------------------------------------------------------------------
r193779 | pfeldman@chromium.org | 2015-04-15T10:42:10.906189Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/bindings/BreakpointManager.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/SourcesPanel.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/common/Settings.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/WatchExpressionsSidebarPane.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/inspector/inspector-test.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/workspace/FileSystemMapping.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/inspector/split-view-expected.txt?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/console/ConsoleView.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/settings/SettingsScreen.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/SourcesView.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/ui/SplitView.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/components/DOMBreakpointsSidebarPane.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/main/Main.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/workspace/FileManager.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/AdvancedSearchView.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/EventListenerBreakpointsSidebarPane.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/TabbedEditorContainer.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/host/InspectorFrontendHost.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/workspace/ExcludedFolderManager.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/Runtime.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/sources/XHRBreakpointsSidebarPane.js?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/inspector/split-view.html?r1=193779&r2=193778&pathrev=193779
   M http://src.chromium.org/viewvc/blink/trunk/Source/devtools/front_end/devtools_app/InspectorFrontendHostImpl.js?r1=193779&r2=193778&pathrev=193779

Revert of Revert of DevTools: allow storing devtools preferences on the browser side. [blink] (patchset #1 id:1 of https://codereview.chromium.org/1088093002/)

Reason for revert:
The test in question is broken, tracked as  crbug.com/472488 .

Original issue's description:
> Revert of DevTools: allow storing devtools preferences on the browser side. [blink] (patchset #6 id:100001 of https://codereview.chromium.org/1066813003/)
> 
> Reason for revert:
> This seems to have badly broken http/tests/inspector/service-workers/service-workers-redundant.html
> 
> See:
> http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Oilpan%20(dbg)/builds/535
> 
> BUG= 472488 
> 
> Original issue's description:
> > DevTools: allow storing devtools preferences on the browser side. [blink]
> > 
> > BUG= 376788 
> > 
> > Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=193715
> 
> TBR=dgozman@chromium.org,pfeldman@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG= 376788 
> 
> Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=193772

TBR=dgozman@chromium.org,mlamouri@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 472488 

Review URL: https://codereview.chromium.org/1085253003
-----------------------------------------------------------------

Comment 56 by rob@robwu.nl, Apr 29 2015

Status: Assigned
Re-opening bug since patches have been reverted.
Status: Fixed
I think everything was re-landed.
We now persist  your appearance preferences (docking position, size, etc) and devtools settings (disable cache, etc) into incognito.

We do not persist these specific items into incognito:
 * console history, workspaces, open files in Sources, XHR breakpoints, global search configuration, breakpoints (JS, DOM, XHR, evt listener), watch expressions

This is in Canary now and will head to beta stable in Chrome 44.

See this comment for the larger explanation and context:
https://code.google.com/p/chromium/issues/detail?id=376788#c45
 Issue 489631  has been merged into this issue.

Comment 60 by a...@chromium.org, Sep 25 2015

 Issue 535670  has been merged into this issue.
How do u get incognito on HP Chromebooks 

Sign in to add a comment