When devtools.workspace.enabled is changed the Workspace menu item display should be toggled

VERIFIED WONTFIX

Status

()

Firefox
Developer Tools
--
enhancement
VERIFIED WONTFIX
7 years ago
7 years ago

People

(Reporter: Erik Vold, Assigned: Erik Vold)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [workspaces])

(Assignee)

Description

7 years ago
Atm the workspace menu item is displayed if the status of devtools.workspace.enabled is true when the window is opened.

Expected Result:

When the pref is changed to true then the workspace menu item should be visibile in all open windows which normally display the menu item. If the pref is changed false then the workspace menu item should not be visible.
(Assignee)

Updated

7 years ago
Assignee: nobody → erikvvold
Whiteboard: [workspaces]
Hi Erik,

The feature is currently working as-designed, though it might be nice if the menu item activated immediately rather than requiring a restart or a new window.

cc'ing Gavin: What do you think?
Whether or not we should have an observer usually depends on how likely it is that the pref will be a) frequently toggled b) by a significant portion of users. This pref doesn't seem likely to meet that bar.
(Assignee)

Comment 3

7 years ago
(In reply to comment #2)
> Whether or not we should have an observer usually depends on how likely it is
> that the pref will be a) frequently toggled b) by a significant portion of
> users. This pref doesn't seem likely to meet that bar.

Well what else can we do for power users besides requiring them to restart the browser or open a new window?

Also, what kind of costs are associated with using an observer?
(In reply to comment #3)
> Well what else can we do for power users besides requiring them to restart the
> browser or open a new window?
I don't think asking them to restart is a high bar.

(In reply to comment #2)
> Whether or not we should have an observer usually depends on how likely it is
> that the pref will be a) frequently toggled b) by a significant portion of
> users. This pref doesn't seem likely to meet that bar.

That sounds kind of arbitrary and subjective. I certainly don't see this pref as being toggled frequently by most people. For those who want it, it'll probably be toggled once and left on (or the opposite, toggled off and left off).

(In reply to comment #4)
> (In reply to comment #3)
> > Well what else can we do for power users besides requiring them to restart the
> > browser or open a new window?
> I don't think asking them to restart is a high bar.

No, but it is annoying. If the code required to do this is relatively simple, shouldn't we take it?
Yes, it's arbitrary and subjective, just like every other decision about taking or not taking a patch :)

This pref is not critical, and everyone seems to agree that it isn't flipped frequently or by many people (it's hidden, after all), so let's not spend any more time debating (let alone implementing and landing).

I don't even really know why we have the pref at all (presumably we'll get rid of it at some point once workspaces is more stable?).
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
(In reply to comment #6)
> I don't even really know why we have the pref at all (presumably we'll get rid
> of it at some point once workspaces is more stable?).
That was my understanding when I reviewed it, although I do not know if it is already filed or not.
Status: RESOLVED → VERIFIED
(Assignee)

Comment 8

7 years ago
(In reply to comment #7)
> (In reply to comment #6)
> > I don't even really know why we have the pref at all (presumably we'll get rid
> > of it at some point once workspaces is more stable?).
> That was my understanding when I reviewed it, although I do not know if it is
> already filed or not.

I'm +1 for removing the pref; I thought it was added for the same reason that devtools.errorconsole.enabled was added..
(Assignee)

Comment 9

7 years ago
(In reply to comment #4)
> (In reply to comment #3)
> > Well what else can we do for power users besides requiring them to restart the
> > browser or open a new window?
> I don't think asking them to restart is a high bar.

I do, what if you have a web console session that you don't want to lose for example, and I'm sure I can come up with more examples of things that can be lost during a restart.

Furthermore what method is provided to users to do a restart? none afaict, they'd have to exit, then start the program again, that's like 3 well spaced out operations at least.
Why would someone suddenly decide to flip that pref in the middle of a debugging session and need their changes to take effect immediately? This scenario isn't realistic. Also, it looks to me like the preference defaults to true anyways (in the patch for bug 642176), so there's no reason for users to ever be flipping this pref to begin with.
The pref was added as part of the new release process. We must be able to turn off new features "just in case". It is defaulted to true. Hopefully we can indeed remove it somewhere down the road. We should file that bug!

Ok, let's move on.
(Assignee)

Comment 12

7 years ago
(In reply to comment #10)
> Why would someone suddenly decide to flip that pref in the middle of a
> debugging session and need their changes to take effect immediately? This
> scenario isn't realistic.

It's the scenario that I hit every time I ever had to enable devtools.errorconsole.enabled which was every time that I created a new profile, until the pref was ignored.

If I was debugging something and wanted to try something out in Workspace based on an error I saw, then I would have to lose (or copy and paste) all of the error(s) details in order to restart Firefox so that I can use Workspace.

Since the devtools.workspace.enabled default is true, which I missed, I agree that this bug can be ignored. If the default changes though..
You need to log in before you can comment on or make changes to this bug.