Closed Bug 1191376 Opened 9 years ago Closed 9 years ago

request: always show toolbar when restoring app

Categories

(Firefox for iOS :: Browser, defect)

Other
iOS
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Tracking Status
fxios + ---
fxios-v4.0 --- affected
fxios-v5.0 --- fixed

People

(Reporter: Gavin, Assigned: maurya1985)

References

(Blocks 1 open bug)

Details

(Keywords: uiwanted, Whiteboard: [parity=safari][nicetohave-1.1][good first bug][lang=swift])

Attachments

(1 file)

48 bytes, text/x-github-pull-request
sleroux
: review+
Details | Review
My most frequent use case for Firefox is launching it quickly to search for something or load a specific page by URL (either in the clipboard, in my memory, or less frequently, from my history). I tend to sometimes keep tabs open to refer to later, but most of the times I launch the app I don't want to deal with them and just want a blank slate. When Firefox launches, depending on what I was doing last, sometimes the top toolbar is collapsed. So I need to do a bit of a "wiggle" (scroll the page slightly) to get it to appear, then tap the location bar, then start typing. Ideally, I would never have to do that wiggle. If the toolbar always appeared after a restore then I wouldn't have to. (There may very well be better ways to optimize this particular use case, of course, so feel free to dupe away to a more general bug about that.)
tracking-fxios: --- → ?
Keywords: uiwanted
Whiteboard: [parity=safari]
Whiteboard: [parity=safari] → [parity=safari][nicetohave-1.1]
Whiteboard: [parity=safari][nicetohave-1.1] → [parity=safari][nicetohave-1.1][good first bug][lang=swift]
Assignee: nobody → maurya1985
Status: NEW → ASSIGNED
Is there a mentor for this bug? I have some changes that might benefit from a review: https://pastebin.mozilla.org/8869143 Essentially, the scenario doesn't exist when the is relaunched after a termination. The scenario exists only when the app is brought back to the foreground from the background. The above changes work as expected. However, in terms of code quality, I thought there might be improvements since I'm accessing the BrowserViewController and BrowserScrollController from the AppDelegate. Any suggestions anyone?
Flags: needinfo?(sleroux)
> However, in terms of code quality, I thought there might be improvements since I'm accessing the BrowserViewController and BrowserScrollController from the AppDelegate. Any suggestions anyone? Eventually I'd like to see us eliminate as much of the coupling between the AppDelegate/BVC as we can. iOS sends out notifications that anyone can listen to for the various foreground/background events. The BVC already listens to these for hiding/showing web content when backgrounding the app while viewing a private tab [1]. Maybe try moving this logic here? [1] https://github.com/mozilla/firefox-ios/blob/master/Client/Frontend/Browser/BrowserViewController.swift#L246
Flags: needinfo?(sleroux)
Attached file Pull request
Attachment #8747684 - Flags: review?(sleroux)
Comment on attachment 8747684 [details] [review] Pull request Great, simple fix. Thanks for the patch!
Attachment #8747684 - Flags: review?(sleroux) → review+
master c9d67a4aea23ec93880fdd6085352222a351eb06
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Verified as fixed latest master (0da9bd79).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: