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.
Haven't we got some sort of onshow event for the document?
Yes, use socialFrameShow. Visibility api should also work, but needs verification.
5 years ago
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)
Whiteboard: [est:1d] → [est:1d][p=1]
Target Milestone: --- → mozilla32
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
Verified fixed through basic dogfooding. Adam, do you think this is worth having a regression test in Moztrap?
Status: RESOLVED → VERIFIED
OS: Mac OS X → All
Hardware: x86 → All
(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.
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.