Open Bug 1608743 Opened 4 years ago Updated 2 years ago

workspace ID field for window extensions object

Categories

(WebExtensions :: Untriaged, enhancement, P5)

Product:
WebExtensions
Component:
Untriaged
Version:
72 Branch
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: contact, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

Currently, the windows.Window object in the Web Extensions API contains the below fields.

alwaysOnTop
focused
height
id
incognito
left
sessionId
state
tabs
title
top
type
width

This information has a variety of uses for extensions, particularly session managers, which persist the data, then later recreate a set of windows corresponding to the saved data set.

Actual results:

Many windowing systems support multiple workspaces, such that the ID of the workspace is a property of each window. However, the API lacks a field for this attribute.

Expected results:

Extensions should be able to query or to alter the workspace to which a window is assigned. Such support would make possible extensions that offer more complete session recovery than offered by current extensions.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Product: Firefox → WebExtensions

longer term, and depends on session restore improvements.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5

I understand that the feature might not be a foremost priority, but are you suggesting that the usefulness is largely tied to future internal improvements in session handling? Currently, various extensions provide a high level of functioning with respect to session management, but are unable to interact with workspaces due to the described limitation in the extensions API. If the proposed feature were made available, extensions could utilize it with trivial enhancements, and in doing so offer a greatly improved user experience.

Depending on difficulty of implementation, which would of course demand a longer time frame, the low priority that has been assigned, might be worth reconsidering.

Also P5 classification is documented as meaning, "We basically never want this". Does this characterization correctly represent your intent?

That documentation should probably be update. We don't use P4 at all. Roughly it would be:

P1 - we're currently working on it, needs to land asap.
P2 - we're planning on working on it soon (next release preferred if possible)
P3 - we think this needs to be one, but it is not scheduled
P4 - we don't use
P5 - We're unsure about this, potentially willing to accept contributions for it, but we're not planning to work on it. P5 is also use often for "first good bugs".

If there is something we actually would not accept we generally try to close the bug with a reason.

In this case, neither the product need or the definition of the feature is well defined, and our comment reflects that.

What information would be needed for you to change your characterization of the request as not "well defined"?

Originally, a list was given of current window attributes appearing in the extensions API, and a particular additional one was requested. More complete session recovery was identified as a key functional benefit to an extension able to utilize this attribute, compared to the capabilities of extensions using the current attribute list.

I am having difficulty imagining what might be considered ambiguous or nebulous.

What information might lead you to upgrade the classification to P3 (needed but unscheduled)?

I am having difficulty imagining what might be considered ambiguous or nebulous.
Extensions should be able to query or to alter the workspace to which a window is assigned. Such support would make possible extensions that offer more complete session recovery than offered by current extensions.

What are some user facing use cases that require the functionality? What functionality is considered altering the workspace? What APIs should support a workspaceID? Does the platform need work to support the use cases and does that fit in cleanly with our current functionality and plans? Is the functionality something that should simply be fixed in our platform vs. adding APIs?

What are some user facing use cases that require the functionality?

The basic use case is that a session-management extension persists details about each window, including its workspace ID. A user later restores that session. Rather than all windows consolidated into the active workspace, they are each assigned to the workspace recorded in the session.

What functionality is considered altering the workspace?

I doubt that a workspace would be altered per se, but the extension would query or assign the workspace ID of a window. If a window is assigned to workspace different from its current one, then the window is visibly moved to the new workspace.

What APIs should support a workspaceID?

I would suggest that the new API features take a form parallel to those relating to similar window attributes, such as width and height. Querying and assigning a workspace to a window follows the same idioms as querying or assigning dimensions.

Does the platform need work to support the use cases and does that fit in cleanly with our current functionality and plans? Is the functionality something that should simply be fixed in our platform vs. adding APIs?

I am not clear about the meaning of your distinction between platform versus APIs, but since the object is to make further data available to extensions, and since the extensions API is currently, as I understand, the only interface for such interaction, the effect of the proposal would be to augment the extensions API such that extension authors have access the further data, namely workspace ID of windows.

I hope these answers clarify your concerns. I respect the need for rigour, but the original request was intended to be contained and straightforward. The questions lead me to wonder whether it has been inferred that the request carries a larger scope or represents a more complicated discussion than actually intended.

Again, the intention is to improve the user experience currently offered by session-management extensions by allowing such extensions to manage workspace assignment of windows, in addition to their other physical attributes, such that users have a more satisfactory experience during session restore operations.

I am not clear about the meaning of your distinction between platform versus APIs

Most extension APIs are simply an abstraction between extensions and the gecko platform.

I know for a fact that the regular session restore does not handle workspaces, so it is very likely that this needs to be handled somewhere in the gecko platform. That could be simple, or it could be very involved.

If you are referring to the implementation difficulty of adding the relevant items to the extensions API, then I would agree that the difficulty is greater in the case that the application does not currently process or store the information that is proposed to be transmitted through the interface via the proposed API changes. However, workspace ID would seem to be information readily accessible via the window manager, much the same as window dimensions, such that no great struggle might be predicted to utilize this data in the application. Thus, even if the new support requires manipulation of many layers of the codebase, the difficulty of each manipulation is likely to be limited.

Beyond these considerations, regular session restore is a red herring. As I hope is understood, the current proposal is squarely intended to extend the range of capabilities possible for an extension, not to extend native support for session restore.

Would you require further details to consider promoting the status of the request? I have attempted to address the questions you previously presented.

I would understand if the reluctance to consider the issue more seriously follows from the complexity in adding support in the platform, which you would consider a dependency for augmenting the API layer, which as you say is merely an abstract interface without independent functionality. Nevertheless the request is functionally an important enhancement to consider when assessing a full set of capabilities to expose to extension authors such that their extensions might offer an optimal user experience.

See Also: → 440895

I don't see the priority of this changing, I think it still fits where we placed it. Even with a very well defined outline we would likely place it in P5. Any other priority indicates that we would potentially get it scheduled for work in our group, I cant see that happening in the short term.

We're a relatively helpful group when it comes to giving some advice around implementing something when someone is able to take on that work.

The user impact of the issue appears to be high. I understand your position, but I hope you might consider a way to schedule the modification.

Bug 440895 was marked resolved, and closed. Perhaps this development would prompt a change in prioritization, based on feasibility and utility, of the proposed enhancement.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.