Loop (and SocialAPI) should go back to using panel subviews (revert part of bug 1047316)

RESOLVED WONTFIX

Status

Hello (Loop)
Client
P3
normal
Rank:
35
RESOLVED WONTFIX
4 years ago
2 years ago

People

(Reporter: jaws, Unassigned)

Tracking

unspecified
Points:
---
Dependency tree / graph
Bug Flags:
firefox-backlog +

Firefox Tracking Flags

(Not tracked)

Details

Bug 1047316 moved Loop and SocialAPI to use separate panels when clicked on from the menu panel, but we should be consistent here and use the built-in subview interactions for both of these.

This change was made due to a time crunch and some bugs that were found, but with more time we should revert that change and fix the bugs that were found and worked-around (see bug 1047316).
Component: SocialAPI → Client
Product: Firefox → Loop
Shortened notes on why it doesn't currently work in the subviews:

The primary issue here is that the status button and loop are using SharedFrame.jsm so they use only one iframe across all windows.  docshell swapping requires that the element has been visible once, and is still "visible" (ie. you cannot display:none).  The subviews in the menu panel get display:none when they are hidden.  The one event that happens (panelshowing or something like that) when the subview is opened happens prior to visibility.
backlog: --- → -
I'm pretty sure this is why we're getting bug 1122858. Hence, I think we should schedule in looking at this sometime soon, as it is bad UX.
Blocks: 1122858
backlog: - → ---
Priority: -- → P3
(In reply to Mark Banner (:standard8) from comment #2)
> I'm pretty sure this is why we're getting bug 1122858. Hence, I think we
> should schedule in looking at this sometime soon, as it is bad UX.

It's not (though yes, panelview would fix this).  You're getting bug 1122858 because you are not adjusting the panel anchor.

Updated

3 years ago
backlog: --- → Fx38?
Rank: 35

Updated

3 years ago
backlog: Fx38? → backlog+
Flags: firefox-backlog+

Comment 4

3 years ago
Dan, is this still a valid bug given the visual refresh or should we close this?
Flags: needinfo?(dmose)
RT: afaik, it's still valid, but I don't know that code well; this bug is all about the code that runs outside of the iframes, and makes some sense from a code cleanliness point-of-view.  Whether it's actually causing any user-visible side-effects, that we care about in the near future is non-obvious to me.  Standard8 would likely know more....
Flags: needinfo?(dmose) → needinfo?(standard8)
We need this because it would let us put the Hello panel back as a sub-panel within the Hamburger menu (like what happens if you click the history/developer options from there).

Hence this would provide less jarring UX for those that have the Hello button in the hamburger menu.
Flags: needinfo?(standard8)
We're not going to see this - see bug 1026453 comment 13.
(In reply to Mark Banner (:standard8) from comment #7)
> We're not going to see this - see bug 1026453 comment 13.

We're not going to *fix* this.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.