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

fix page position on navigation #2330

Merged
merged 18 commits into from
Jan 15, 2024
Merged

Conversation

brindy
Copy link
Contributor

@brindy brindy commented Jan 11, 2024

Task/Issue URL: https://app.asana.com/0/715106103902962/1205688349294686/f
Tech Design URL:
CC:

Description:
Fixes the following bugs:

  • page position would be forgotten on navigation
  • scrolling would stop when user scrolls the webview and the bars are being hidden

Steps to test this PR:

On both iPhone and iPad, ideally on a device:

  • Browse the web and use backwards and forwards navigation. The page position should not change on navigation.
  • Check different orientations
  • Check keyboard adjusts the webview correctly as needed (when entering fields on the page)
  • Check the browsing menu appears in the expected location

On iPhone specifically (or iPad when in small mode on split view):

  • Check browsing with top and bottom address bar positions (bottom bar position not available on iPad unless in “small” mode / split screen)
  • Check scrolling hides and shows the bar as previous, but does not stop the page scrolling
  • Quick swipe should hide show bars as previous
  • When at bottom of the screen over scrolling should show bars as previous

@duckduckgo duckduckgo deleted a comment from github-actions bot Jan 11, 2024
@brindy brindy marked this pull request as ready for review January 12, 2024 13:21
@brindy brindy requested review from a team, amddg44 and THISISDINOSAUR and removed request for a team and amddg44 January 12, 2024 13:35

var offset = scrollView.contentOffset
offset.y = transitionStartPosY
scrollView.contentOffset = offset
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

adjusting the content offset while it was scrolling is what causes the page to stop scrolling while the bars are being hidden, which is not what other browsers do and at least one person internally has complained about

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know why we were doing this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really, but it's been flagged as a bug since and does seem inconsistent with other browsers and personally I think it is a bit annoying :)

return min(normalizedDistance / barsHeight, 1.0)
// We used to fix the scroll position in place as the transition happened
// but now the bars disappear too. This adjusts for that.
let transitionSpeed = 0.5
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is related to the content offset code removal above.

@@ -38,7 +38,6 @@ protocol BrowserChromeDelegate: AnyObject {
class BrowserChromeManager: NSObject, UIScrollViewDelegate {

struct Constants {
static let dragThreshold: CGFloat = 30
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unused

@@ -61,7 +61,7 @@ final class BrowsingMenuAnimator: NSObject, UIViewControllerAnimatedTransitionin
transitionContext.containerView.addSubview(fromSnapshot)
}

toViewController.bindConstraints(to: fromViewController.currentTab?.webView)
toViewController.bindConstraints(to: fromViewController.viewCoordinator.contentContainer)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the web view can now be as big as the app so is the wrong thing to base the browsing menu on

self.webView = webView
self.webViewFrameObserver = webView?.observe(\.frame, options: [.initial]) { [weak self] webView, _ in
self?.recalculateMenuConstraints(with: webView)
private weak var guideView: UIView?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since it's no longer a web view now, I've renamed it to match its purpose

@@ -137,6 +137,8 @@ class MainViewController: UIViewController {

// Skip SERP flow (focusing on autocomplete logic) and prepare for new navigation when selecting search bar
private var skipSERPFlow = true

private var keyboardHeight: CGFloat = 0.0
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Set when the keyboard frame changes so that it can be used when refreshing the content insets for the web view

@@ -872,18 +876,29 @@ class MainViewController: UIViewController {
}
}

private func addToView(tab: TabViewController) {
private func addToWebViewContainer(tab: TabViewController) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

renamed to reflect purpose instead of unclear overloaded names

tab.progressWorker.progressBar = viewCoordinator.progress
chromeManager.attach(to: tab.webView.scrollView)
tab.chromeDelegate = self
}

private func addToView(controller: UIViewController) {
private func addToContentContainer(controller: UIViewController) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

renamed to reflect purpose

removeHomeScreen()
updateFindInPage()
currentTab?.progressWorker.progressBar = nil
currentTab?.chromeDelegate = nil
addToView(controller: tab)
currentTab?.webView.scrollView.contentInsetAdjustmentBehavior = .never
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

iOS does weird stuff if this not disabled, once you start messing with the content insets

height: webView.frame.size.height - webView.scrollView.contentInset.top - webView.scrollView.contentInset.bottom)

UIGraphicsBeginImageContextWithOptions(size, false, UIScreen.main.scale)
UIGraphicsGetCurrentContext()?.translateBy(x: 0, y: -webView.scrollView.contentInset.top)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we're only interested in the bit of the screen currently visible - without this we end up with potentially blank space

@brindy
Copy link
Contributor Author

brindy commented Jan 12, 2024

Just did a bit of a self review and pushed a couple of commits. I'm definitely done now @THISISDINOSAUR when you're ready. Thanks!

Copy link
Contributor

@THISISDINOSAUR THISISDINOSAUR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!
The change with scrolling when the URL bar is at the bottom is way better.

I haven't been able to get it to forget the scroll position, but that bug was always really hard to replicate. It at least doesn't seem worse 😅

@brindy
Copy link
Contributor Author

brindy commented Jan 15, 2024

Thank you!

@brindy brindy merged commit 8b94de5 into main Jan 15, 2024
11 checks passed
@brindy brindy deleted the brindy/fix-page-position-on-navigation branch January 15, 2024 16:40
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

Successfully merging this pull request may close these issues.

2 participants