Closed
Bug 1057472
Opened 10 years ago
Closed 8 years ago
Loop (and SocialAPI) should go back to using panel subviews (revert part of bug 1047316)
Categories
(Hello (Loop) :: Client, defect, P3)
Hello (Loop)
Client
Tracking
(Not tracked)
RESOLVED
WONTFIX
backlog | backlog+ |
People
(Reporter: jaws, Unassigned)
References
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).
Reporter | ||
Updated•10 years ago
|
Component: SocialAPI → Client
Product: Firefox → Loop
Comment 1•10 years ago
|
||
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.
Updated•10 years ago
|
backlog: --- → -
Comment 2•9 years ago
|
||
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.
Comment 3•9 years ago
|
||
(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•9 years ago
|
backlog: --- → Fx38?
Rank: 35
Updated•9 years ago
|
backlog: Fx38? → backlog+
Flags: firefox-backlog+
Comment 4•9 years ago
|
||
Dan, is this still a valid bug given the visual refresh or should we close this?
Flags: needinfo?(dmose)
Comment 5•9 years ago
|
||
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)
Comment 6•9 years ago
|
||
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)
Comment 7•8 years ago
|
||
We're not going to see this - see bug 1026453 comment 13.
Comment 8•8 years ago
|
||
(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
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•