1158503 - Adding item to Reading List by long-pressing Reader mode button issues no feedback

Status: NEW

(Firefox for iOS :: Browser, defect)

Description

[Boris Dušek]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/600.5.17 (KHTML, like Gecko) Version/8.0.5 Safari/600.5.17

Steps to reproduce:

1. Open a webpage that has reader mode available (e.g. http://en.m.wikipedia.org/wiki/Mozilla_Firefox :-)
2. Long-press the Reader mode icon in the url bar to add the item to the Reading List


Actual results:

Absolutely nothing, except when I go to reading list afterwards (tap location label, press Reading List icon), I find the webpage was added there. So one cannot be sure if they pressed the button long enough, or if they were not missing the reader mode button by a few pixels (i.e. one cannot be sure if the item got added to Reading List).


Expected results:

On top of "What happened?", some indication to the user that the item was added successfully to the Reading List. Maybe fly an icon of the webpage from the reader mode button to some "reading list land"? :-) If reading list was in the bottom toolbar, we would be set as we would fly it there, but without it there or anywhere on the main screen, something more clever will need to be devised.

Or maybe better, display a translucent banner for 1 second in the middle of the screen saying "Added to reading list" with some bigger bold font?.

Also if the chosen way of feedback is not accessible to VoiceOver (for example if the feedback will be realized by some animations similar to what I described), then accessibility will have to be ensured (e.g. by UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification, NSLocalizedString("Added to reading list", comment: "")).

Comment 1

[Boris Dušek]

Related to https://bugzilla.mozilla.org/show_bug.cgi?id=1152697 (just the VoiceOver part, but I think it should be in one integral bug).

Comment 2

[Stephan Leroux [:sleroux]]

Attachment: PR

(Copied from Github)

Finally got this working right.

The idea now is that instead of setting contentInsets on the WKWebView's scroll view, the view is pinned to the toolbars using constraints so as they animate, the web view will expand. The additional trick in this branch is turning off the scrollView layer's maskToBounds property so the web content will render outside of the scroll view, beneath the toolbars.

Additionally, I wrapped the showToolbars call in the scrollViewWillEndDragging method with a dispatch_async block to allow the scroll view to handle it's own animation first on the main queue and run the toolbar animation after so position:fixed elements on the page don't jump around.

Last thing, I added a minimum content size for which the toolbars actually scroll away at. I noticed Safari does the same thing where if a page is too short or a fixed size, don't try to scroll away the toolbars.

Comment 3

[Stephan Leroux [:sleroux]]

Oops wrong bug.

Comment 4

[Boris Dušek]

:-)