Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pasteboard URL toasts when multiple windows open #20278

Open
data-sync-user opened this issue May 16, 2024 · 4 comments
Open

Pasteboard URL toasts when multiple windows open #20278

data-sync-user opened this issue May 16, 2024 · 4 comments

Comments

@data-sync-user
Copy link
Collaborator

data-sync-user commented May 16, 2024

Need to investigate a potential solution for multi-window MVP for pasteboard URL toasts on iPad. (This may require feedback from UX team post-MVP.)

Steps:

  1. Enable Offer to Open Copied Links
  2. Open multiple windows on iPad
  3. Copy a URL to the pasteboard in another app
  4. Bring firefox forward

Result: Currently, with multiple windows open, all of them will show a toast.

We should investigate/discuss the UX implications of this and (ideally) explore options for providing a better user experience, though that may need to happen post-MVP.

!Simulator Screenshot - iPad (10th generation) - 2024-05-15 at 22.42.29.png|width=2360,height=1640,alt="Simulator Screenshot - iPad (10th generation) - 2024-05-15 at 22.42.29.png"!

┆Issue is synchronized with this Jira Task

@data-sync-user
Copy link
Collaborator Author

➤ Matt Reagan commented:

This is a slightly-tricky situation both from a technical and UX perspective; if the user has multiple windows open, and copies a URL to the pasteboard, and then opens Firefox, we have no idea which iPad window(s) they will want to open the tab in. Currently, the toast will show for all windows for a brief period, and they can tap the Go button in whichever window they want (or more than one). Any toasts that aren’t explicitly dismissed will disappear after the standard delay.

My inclination for the multi-window MVP is that the best solution will be to keep this current behavior as-is (most other solutions will likely require new UI which will need to be discussed in further depth with the UX team).

LMK if anyone has concerns or wants to discuss this further. I’ll keep this ticket open in the meantime. Thank you (cc Norberto Andres FurlanNicole Weber Jeremy Evans)

@data-sync-user
Copy link
Collaborator Author

➤ Nicole Weber commented:

Thanks, Matt Reagan! This makes sense to me: we give users the option to select which window to open it in and then the toast in the other window automatically disappear; this is not too bad 🙂

Can the different instances talk to each other? I was wondering if we could send a signal to the other window and then immediately dismiss the toast when the user opened it?

@data-sync-user
Copy link
Collaborator Author

➤ Matt Reagan commented:

Nicole Weber Right now if you tap Go in one toast, the others will not automatically dismiss, they would only disappear after the usual timeout delay. We could add support for them to dismiss immediately, however. I think it’s just a question of if it’s something we want to prioritize for the MVP which is probably a decision for you and Norberto Andres Furlan. From the dev side I think the LOE for that should be relatively low. Just LMK if we should prioritize this (or you can file a ticket on the parent epic and I can take a look). Thank you

@data-sync-user
Copy link
Collaborator Author

➤ Nicole Weber commented:

I’ll defer to Andy to prioritize this against all the other work y’all have going on – as mentioned, I don’t think it’s terrible as-is, might be a little irritating but not a deal breaker at all. Thanks1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant