Firefox-ios: Make it possible to disable link previews on iOS 13

Created on 28 Jan 2020  Â·  10Comments  Â·  Source: mozilla-mobile/firefox-ios

Using Firefox 21.0 (16918) on iOS 13.3, when tapping-and-holding a link to open the context menu to copy/share the link, an intrusive popup preview of the linked page is displayed, pushing the context menu off-screen.

To copy/share the link, one must swipe up to reduce the size of the link preview every time. Another unintended consequence is that copying a link loads the target page.

The preview popup cannot be disabled in Firefox, but it can in Safari. Please consider adding an option to disable it, or even better, a default-off setting, fitting for a privacy-conscious browser.

Steps to reproduce

Open https://mozilla.org. For reference, the page looks similar to:

0_mozilla_org

Tap-and-hold the Firefox for iOS button in the middle of the page to display the link context menu.

The link preview popup appears, occupying most of the screen; note the share/copy link options are pushed off the screen:

1_firefox_copy_link_invisible

Swipe up to shrink the link preview popup, which makes room for the context menu. One must do this every time to access the share/copy options:

2_firefox_copy_link_visible_after_drag_up

Expected behavior

Similar to Safari, allow disabling the link preview popup permanently. Ideally, disable the link previews by default to protect user privacy, unless they opt-in to them explicitly.

As a reference point, Safari shows a Hide preview option, highlighted below:
3_safari_option_hide_preview

Clicking it collapses and disables further preview popups. Once disabled, tap-and-holding any other link shows only the context menu options but leaves out the preview until manually re-enabled:

3_safari_copy_link_visible_when_hidden

Observed behavior

To access the options to download/copy/share a link, one must swipe up to reduce the size of the link preview every time, when using Firefox.

Loading the link target every time wastes battery, bandwidth, and impacts user privacy unnecessarily. None of this should happen unless the user explicitly opts-in to have such previews displayed.

QA Verified contrib-patch

Most helpful comment

Thank you very much, @cscgh and @garvankeeley!
Much appreciated.

That thanks goes to @q2r5 for adding the opt-out configuration in a hurry. Thank you!

All 10 comments

Also reproduces on version 22.0 (17157).

edit: The below mentioned commit had a failed build status. As mentioned, I lack familiarity here. —csc

This would appear to be due to a commit by @garvankeeley in approval of a change made for #5616/#5737 by @q2r5 re: “Showing a preview brings the context menu closer to the bottom of the screen for easier use, and brings us closer to parity with Safari.”, Nov 12 for inclusion in v21, to BrowserViewController+WebViewDelegates.swift

This change implemented the preview view but omitted the Safari “hide preview” option.

Can a high priority level be given to this on assignment? The inability to identify a link target before clicking on it or having the browser ‘click’ it for you is not insignificant. I feel it will take me longer than seriousness demands to do it myself lacking familiarity with the process, project, non-trivial git, xcode, and IOS or GUI development. That’s so many rabbit holes. Thank you so much for your work.

—csc

Backed out c829026 in a local copy and built w/ defaults w/o additional warnings. Ran simulated on iPad Air 3 and iPhone 11 Pro Max, 13.3 and 13.2 respectively. Context menu without previews again. Made the change in a forked repository but figuring out the rules on participation, pull/review/discuss requests, et al. Hope to discuss getting previews backed out in a quicker update until a corresponding hide option can be created.

Of note, the content menu previewView is also launching directly into authorization/authentication processes when the target link demands it, disrupting the browsing session is the process.

Still reproduces on v23.0 (17297).
Is there some idea about a timeline for a fix to be integrated?

Still reproduces as reported on v24.1 (17574)

Thank you very much, @cscgh and @garvankeeley!
Much appreciated.

Thank you very much, @cscgh and @garvankeeley!
Much appreciated.

That thanks goes to @q2r5 for adding the opt-out configuration in a hurry. Thank you!

Verified as fixed on master 6865276c8f4c.

This will land for v26, not v25, to allow time for L10N on the string changes.

Was this page helpful?
0 / 5 - 0 ratings