1109641 - Disable the back/forward buttons when there is nothing to do

Status: RESOLVED FIXED

(Firefox for iOS :: Browser, defect)

Description

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Disable the back/forward buttons when there is nothing to do.

Comment 1

[Sachin Palewar]

Buttons are private so can't be disabled from outside the toolbar class/object. Should we make them public? Or should we create 2 separate methods in toolbar for disabling  each button?

Also when should these methods be triggered? Should we use WKNavigationDelegate and may be trigger these methods from - webView:didCommitNavigation: - here we check if these is anything in the list, if there isn't, then we disable?

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

Brainstorming:

It doesn't look like we have any code that tracks the WKWebView navigation progress yet. I assume the BrowserViewController could do that. The BrowserToolbar should probably have a method that allows the controller to update it's state after a page loads (or fails to load). We'll need to update the URL as well, for example. The state we pass into that BrowserToolbar method should have enough information for the toolbar to set the state of the buttons.

Comment 3

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Using KVO you can watch the WKWebView's canGoBack and canGoForward properties and update the UI accordingly.

Comment 4

[Chuong Vu]

I like the KVO idea, it's similar to how the progress bar is being tracked. In addition to the KVO, you have to take into account when switching tabs now. So update the UI accordingly whenever a new tab is switched to since you are dealing with a new webView. This I would bet be made in -- didSelectedTabChange

Comment 5

[Sachin Palewar]

Somebody already submitted a PR for it - https://github.com/mozilla/firefox-ios/pull/53. Haven't had time to look at it though.

Comment 6

[Brian Nicholson (:bnicholson)]

Attachment: Pull request

apbendi has a PR for this. We can't use KVO directly as suggested in comment 3 since canGoBack/canGoForward are not KVO-compliant properties. I suggest updating the back/forward state in webViewDidStartLoad, when a page begins loading.

Comment 7

[Brian Nicholson (:bnicholson)]

Comment on attachment 8544287 [details] [review]
Pull request

Merged awhile ago. Looks like I forgot to update this bug.