Closed
Bug 901899
Opened 11 years ago
Closed 11 years ago
Add testBrowserSearchVisibility
Categories
(Firefox for Android Graveyard :: Awesomescreen, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
Firefox 26
People
(Reporter: lucasr, Assigned: lucasr)
References
Details
(Whiteboard: [fixed-fig])
Attachments
(1 file)
3.89 KB,
patch
|
Margaret
:
feedback+
|
Details | Diff | Splinter Review |
To test the visibility behaviour for BrowserSearch.
Assignee | ||
Comment 1•11 years ago
|
||
Attachment #786226 -
Flags: review?(margaret.leibovic)
Comment 2•11 years ago
|
||
Comment on attachment 786226 [details] [diff] [review] Add testBrowserSearchVisility Review of attachment 786226 [details] [diff] [review]: ----------------------------------------------------------------- Nice, I really like this! I just have one concern about the logic in assertBrowserSearchVisibility ::: mobile/android/base/tests/testBrowserSearchVisibility.java.in @@ +67,5 @@ > + final View v = browserSearch.getView(); > + if (isVisible && v != null && v.getVisibility() == View.VISIBLE) > + return true; > + > + return false; What if we're trying to assert that BrowserSearch isn't visible (isVisible = false)... Shouldn't we then still return true if (!isVisible && v != null && v.getVisibility() != View.VISIBLE) ? Or is it only not visible if the Fragment is null? At the very least, some more comments here would be good to help clarify this logic, since it can be hard to reason through (at least for me :)
Attachment #786226 -
Flags: review?(margaret.leibovic) → feedback+
Assignee | ||
Comment 3•11 years ago
|
||
(In reply to :Margaret Leibovic from comment #2) > Comment on attachment 786226 [details] [diff] [review] > Add testBrowserSearchVisility > > Review of attachment 786226 [details] [diff] [review]: > ----------------------------------------------------------------- > > Nice, I really like this! I just have one concern about the logic in > assertBrowserSearchVisibility > > ::: mobile/android/base/tests/testBrowserSearchVisibility.java.in > @@ +67,5 @@ > > + final View v = browserSearch.getView(); > > + if (isVisible && v != null && v.getVisibility() == View.VISIBLE) > > + return true; > > + > > + return false; > > What if we're trying to assert that BrowserSearch isn't visible (isVisible = > false)... Shouldn't we then still return true if (!isVisible && v != null && > v.getVisibility() != View.VISIBLE) ? Or is it only not visible if the > Fragment is null? At the very least, some more comments here would be good > to help clarify this logic, since it can be hard to reason through (at least > for me :) I should have probably added a comment about this. What we're testing here is not only that the BrowserSearch fragment's view is not "visible" but also that the fragment itself has been completely removed from the app. If a fragment is present (in the fragment manager) but its view is null, this just means it has been detached but not necessarily removed (which is not what we're testing here). So, I'll add a comment explaining this for clarity.
Assignee | ||
Comment 4•11 years ago
|
||
Pushed: http://hg.mozilla.org/projects/fig/rev/8a36903511fd
Whiteboard: [fixed-fig]
Comment 5•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/8a36903511fd
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 26
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•