Closed Bug 1497965 Opened 7 years ago Closed 6 years ago

Make toast views stretch all the way to the bottom of the screen

Categories

(Firefox for iOS :: General, enhancement)

Other
iOS
enhancement
Not set
normal

Tracking

()

RESOLVED INACTIVE
Tracking Status
fxios ? ---

People

(Reporter: justindarc, Assigned: rahul.rrixe)

References

Details

(Whiteboard: [GoodFirstBug])

Attachments

(2 files)

As a follow-up to Bug 1497441, let's extend the bottom of the toast to reach the bottom of the screen so that the web content is not visible below it when the bottom toolbar is not on-screen.
Depends on: 1497441
Priority: -- → P2
Priority: P2 → P3
Attached image image.png

Hi @justindarc, I can work on it. I think it is a good starter bug for me. You can assign it to me.

Also, if you have more code context then please share unless I will try my best.

Great! Thanks!

I believe this is the base Toast class that the others extend:

https://github.com/mozilla-mobile/firefox-ios/blob/master/Client/Frontend/Browser/Toast.swift

There is one other SimpleToast class for toasts that don't have a button or anything:

https://github.com/mozilla-mobile/firefox-ios/blob/master/Client/Frontend/Browser/SimpleToast.swift

However, in the case of this bug, I believe the toasts in question that need fixed all extend from the base Toast class. The easiest way to test this is to long-press a link and "Open in New Tab" to see the toast you see in Comment 2.

Assignee: nobody → rahul.rrixe
Status: NEW → ASSIGNED
Whiteboard: [GoodFirstBug]

Thanks, Justin for detailed context, I have started working on it.

Zero constraints cover the TabToolBar.

Justin, I have looked into the code. We have several cases to handle here.

Case 1: Existing one.
Currently, toast bottom anchor has a constraint to webViewContainer safeArea and that's why we see the text below it.

self.webViewContainer?.safeArea.bottom 

Case 2: Removing the above constraint and making it to zero

If I make the bottom constraint to zero then it overlaps on the TabToolBar before scrolling and style also change like the side corner.
I don't know what is the correct design here.

make.bottom.equalTo(self.webViewContainer?.safeArea.bottom)

Case 3: Scroll View
In this case, while TabToolBar is there then we can show the toast above it and once it is not present while scrolling then we can show a toast with zero constraints like the above image. In this scenario, we have to little bit fiddle with ScrollViewDelegate.

Flags: needinfo?(jdarcangelo)

Sorry if this has turned into a bit of a rabbit-hole.

So, I believe the desired behavior here is for the bottom of the toast to behave exactly the same as it does currently in all cases except for when the bottom tab toolbar is hidden. In that case, the problem is that there's a gap between the bottom of the toast and the bottom of the screen. What we'd like to do is extend the background blue area of the toast to go all the way to the bottom. This may require tweaking the view hierarchy within the toast view itself. In cases where the bottom tab toolbar is visible, the current behavior of the toast bottom touching the top of the toolbar is correct and no additional padding seems to be needed.

In my naïve way of looking at this problem, I would try and see if there's a way to place the toast view behind the bottom tab toolbar, but above the webview. In that case, you could simply build in some permanent bottom padding to the toast view so that it will always extend to the bottom of the screen and just adjust the vertical positioning of the toast depending on whether or not the bottom tab toolbar is visible.

Flags: needinfo?(jdarcangelo)

Sounds good now. I think we stumbled upon corner cases only when we are fixing and so it is OK (no rabbit-hole).

One more question, so let say I fix this. After this, do we have units test also or just UI tests to write?

Priority: P3 → --

Bug has been migrated to Github. Closing.
To add additional comments please find the bug in Github.

https://github.com/mozilla-mobile/firefox-ios/issues

Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: