Have a better way to handle about:home visibility state with BrowserSearch

NEW
Unassigned

Status

()

defect
6 years ago
10 months ago

People

(Reporter: sriram, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

When keyboard is dismissed in BrowserSearch, at times about:home wasn't shown. This was fixed in Bug 911830, though a better cleanup is needed.
Blocks: 911830
Why is the HomePager hidden in BrowserApp.filterEditingMode[1]? Doesn't browserSearch draw directly over the HomePager? If we don't change the visibility for the HomePager, we wouldn't need the band-aid in bug 911830.

[1]: https://mxr.mozilla.org/mozilla-central/source/mobile/android/base/BrowserApp.java?rev=f1b97193d162#1529
That's probably for overdraw problems I guess. Basically when someone is searching, we don't need to hold on to other fragments.
Flags: needinfo?(sriram)
(In reply to Michael Comella (:mcomella) from comment #1)
> Why is the HomePager hidden in BrowserApp.filterEditingMode[1]? Doesn't
> browserSearch draw directly over the HomePager? If we don't change the
> visibility for the HomePager, we wouldn't need the band-aid in bug 911830.
> 
> [1]:
> https://mxr.mozilla.org/mozilla-central/source/mobile/android/base/
> BrowserApp.java?rev=f1b97193d162#1529

This was added to avoid having the accessibility focus on the about:home views underneath the search results UI (see bug 906670).
Semi-related idea: Perhaps we should be using an event system to handle view visibility changes with the LayerView/HomePager/BrowserSearch (e.g. "BrowserSearchHideEvent" would display the HomePager) as it seems particularly fragile now (I believe bug 929088 was caused by this fragility).
Just so this doesn't get lost, lucasr came up with the idea of just updating what's displayed in the "contentArea" in a single function (rather than the event bus from comment 4) and wrote up this not entirely functional sample on the idea.
You need to log in before you can comment on or make changes to this bug.