Loop client should reset panel when activated

VERIFIED FIXED in mozilla33

Status

P1
normal
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: abr, Unassigned)

Tracking

unspecified
mozilla33
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [est:1d][p=1])

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Currently, when one clicks on the Loop icon (presently, a phone handset), the drop-down panel state is whatever was last in that panel. While this is probably the correct behavior once we have an address book to display, right now, it leads to some odd behaviors:

1) If a URL was generated, then dropping down the box again will display the same URL. This runs counter to the intention that these URLs should be individually generated.
2) If an error was generated (e.g., "could not generate URL"), and the window is closed, that error is still displayed.

I assume there is some event we can intercept (either when the pane becomes invisible, or when it is about to become visible) that would allow us to reset it to its initial state. We need to add this functionality before MLP.
I'm not aware of such an event to listen to and I can't find any doc about it, but :mixedpuppy might know.
Flags: needinfo?(mixedpuppy)
Haven't we got some sort of onshow event for the document?
Priority: -- → P3
Yes, use socialFrameShow.  Visibility api should also work, but needs verification.
Flags: needinfo?(mixedpuppy)
Whiteboard: [est:?]
Whiteboard: [est:?] → [est:1d]
backlog: --- → mlp+
Assignee: nobody → nperriault
Created attachment 8413845 [details] [review]
https://github.com/adamroach/gecko-dev/pull/19

This patch uses the DOM visibility API, which is implemented in Desktop and works fairly great.

dmose, please take over the patch if you want DOM integration tests, I felt like unit tests & stubs were enough here.
Attachment #8413845 - Flags: review?(dmose)

Updated

5 years ago
Whiteboard: [est:1d] → [est:1d][p=1]
Target Milestone: --- → mozilla32

Updated

5 years ago
Priority: P3 → P1
Comment on attachment 8413845 [details] [review]
https://github.com/adamroach/gecko-dev/pull/19

r=dmose. Review notes and requests in the PR; please address as appropriate and squash before merging.

Thanks for the patch!
Attachment #8413845 - Flags: review?(dmose) → review+
Landed on loop-ui-initial with r=dmose: https://github.com/adamroach/gecko-dev/commit/e12cdb6a6285ecbb777d4e7893666328ddb6bc65
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: mozilla32 → mozilla33
Verified fixed through basic dogfooding. Adam, do you think this is worth having a regression test in Moztrap?
Status: RESOLVED → VERIFIED
Flags: needinfo?(adam)
OS: Mac OS X → All
Hardware: x86 → All
(Reporter)

Comment 11

5 years ago
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #10)
> Verified fixed through basic dogfooding. Adam, do you think this is worth
> having a regression test in Moztrap?

Short version: not yet.

Full version: it's going to be kind of tricky to put together a regression test will last very long, since this behavior will shortly change so that the URL changes only if it's been copied or shared. Long-term, we're going to want to test that "the right thing" happens when the panel opens, but I would hold off until we have the final UX implemented.
Flags: needinfo?(adam)
Thanks for the detailed response, Adam. Please needinfo me when you feel this needs to get a regression test.
You need to log in before you can comment on or make changes to this bug.