-
Notifications
You must be signed in to change notification settings - Fork 472
Add toolbarVisible getter to WebAppHideToolbarFeature #7216
Conversation
Codecov Report
@@ Coverage Diff @@
## master #7216 +/- ##
============================================
- Coverage 77.24% 77.21% -0.04%
- Complexity 4954 4973 +19
============================================
Files 660 657 -3
Lines 24326 24421 +95
Branches 3575 3581 +6
============================================
+ Hits 18790 18856 +66
- Misses 4063 4070 +7
- Partials 1473 1495 +22 Continue to review full report at Codecov.
|
Please add an issue as reference so we know which bug this is fixing. 🙂 |
Added mozilla-mobile/fenix#10452 to the description |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to see the fenix side of this as well. To me this looks like an ergonomic change. I.e. without this change, in fenix can't you already query visibility directly via the the toolbar view, toolbar.visibility
.
Or do you not have easy access to toolbar
where you'd need it?
Fenix sets the visibility field in other places, so this is used to query what the feature thinks the toolbar visibility should be, rather than what it is. |
That just sounds like a recipe for other bugs to crop up. Can we have a single point of responsibility for controlling toolbar visibility? |
I think this is best for a quick fix (just requires an extra if statment in Fenix), and I'll work on a follow up to move most of this logic into BrowserStore. Eventually we can have something along the lines of: fun SessionState.hideToolbar() = content.fullscreen || content.pictureInPicture || content.url.isInScope() |
I've set up an alternative BrowserStore based solution here: #7251 |
We can close this, right? @NotWoods |
Exposing this to fix the toolbar issues in Fenix. mozilla-mobile/fenix#10452
Pull Request checklist
After merge