Search engine choices pane is completely blank

VERIFIED FIXED in Firefox 26

Status

()

defect
VERIFIED FIXED
6 years ago
3 years ago

People

(Reporter: liuche, Assigned: bnicholson)

Tracking

Trunk
Firefox 27
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox24 unaffected, firefox25 unaffected, firefox26 fixed, firefox27 verified, fennec26+)

Details

Attachments

(2 attachments)

Reporter

Description

6 years ago
On the search engines state for the new about:home, we can reach a state where the search shortcuts pane is completely blank.

STR:
1. Type into search bar to bring up search shortcuts.
2. Scroll on the search shortcuts (this dismisses the keyboard).
3. Tap on the menu bar; this highlights the text and brings up the keyboard.
4. Start typing.

Expected:
Search shortcuts pop up to match the entered text

Actual:
Entire pane goes blank, see screenshot.

Note: Dismissing the keyboard via the back key and starting to type again does not cause this problem.
I'm not able to reproduce, maybe others can? Sounds bad, tracking?
tracking-fennec: --- → ?
I can't reproduce this either, but I'm seeing a terrible glitch when the keyboard dismisses where it looks like we draw the list of search suggestions twice momentarily :/
I am able to reproduce this on Samsung Galaxy Nexus (Android 4.1.1) with SwiftKey keyboard. I will try to find a regression range.
Regression window-wanted:

There are three builds in 08/21 central, when fig has been pushed to m-c. The first build is not affected and the second one is affected.
The pushlog is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d136c8999d96&tochange=b2486721572e
... so new-about-home
Flags: needinfo?(lucasr.at.mozilla)
(In reply to Teodora Vermesan (:TeoVermesan) from comment #4)
> Regression window-wanted:
> 
> There are three builds in 08/21 central, when fig has been pushed to m-c.
> The first build is not affected and the second one is affected.
> The pushlog is:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=d136c8999d96&tochange=b2486721572e

Do you mean that the first nightly with new-about-home was working fine? It would be nice to know what changed between the first and second builds.
Flags: needinfo?(lucasr.at.mozilla)
The first build from 08/21 is unaffected and it is with the old about:home. The second build from 08/21 is the affected one, with the new about:home
(In reply to Teodora Vermesan (:TeoVermesan) from comment #7)
> The first build from 08/21 is unaffected and it is with the old about:home.
> The second build from 08/21 is the affected one, with the new about:home

Just to confirm: does this only happen with the SwiftKey keyboard?
(In reply to Lucas Rocha (:lucasr) from comment #8)
> Just to confirm: does this only happen with the SwiftKey keyboard?

Yes, I am not able to reproduce with other keyboards.
Jim - Are there any gotcha's with swiftkey we should be looking for? Can you look at the logs for any issues?
Assignee: nobody → bnicholson
tracking-fennec: ? → 26+
Flags: needinfo?(nchen)
I did some logging. When typing to replace existing, selected text, SwiftKey deletes the selected text first, before committing new text. This is different from the stock keyboard behavior which commits the new text directly and relies on the editor to delete the old text.

For example, if the current text is "foo" and selected, SwiftKey will call DeleteText(0, 3) then InsertText("bar"), whereas the stock keyboard only calls InsertText("bar"). The result is the same but SwiftKey makes an extra call.

In SwiftKey's case, the text field is temporarily blank due to the DeleteText call, so maybe that messes up the search code.
Flags: needinfo?(nchen)
Assignee

Comment 12

6 years ago
As Jim said, SwiftKey deletes the text before committing new text. This triggers hideBrowserSearch() since the text is empty, then showBrowserSearch() immediately after for the committed text.

When this happens, the container given to BrowserSearch#onCreateView is null. I assume this is an Android bug, and I filed it as http://code.google.com/p/android/issues/detail?id=61179. Calling FragmentManager#executePendingTransactions seems to work as a workaround.
Attachment #818792 - Flags: review?(lucasr.at.mozilla)
Comment on attachment 818792 [details] [diff] [review]
Force execution of pending BrowserSearch fragment removals before re-adding

Review of attachment 818792 [details] [diff] [review]:
-----------------------------------------------------------------

Nice catch.

::: mobile/android/base/BrowserApp.java
@@ +1607,5 @@
> +        // (see bug 925012). Because of an Android bug (http://code.google.com/p/android/issues/detail?id=61179),
> +        // calling FragmentTransaction#add immediately after FragmentTransaction#remove won't add the fragment's
> +        // view to the layout. Calling FragmentManager#executePendingTransactions before re-adding the fragment
> +        // prevents this issue.
> +        getSupportFragmentManager().executePendingTransactions();

nit: getSupportFragmentManager() only once and use it for both calls:

final FragmentManager fm = getSupportFragmentManager();

fm.executePendingTransactions();
fm.beginTransaction()...
Attachment #818792 - Flags: review?(lucasr.at.mozilla) → review+
Assignee

Comment 15

6 years ago
Comment on attachment 818792 [details] [diff] [review]
Force execution of pending BrowserSearch fragment removals before re-adding

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 862793
User impact if declined: search screen can be blank with SwiftKey keyboard (see screenshot)
Testing completed (on m-c, etc.): locally
Risk to taking this patch (and alternatives if risky): very low risk
String or IDL/UUID changes made by this patch: none
Attachment #818792 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/6cf99173cf98
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 27
Flags: needinfo?(teodora.vermesan)
Keywords: verifyme
Verified fixed on:
Build: Firefox for Android 27.0a1 (2013-10-20)
Device: Samsung Galaxy Nexus
OS: Android 4.1.1
Flags: needinfo?(teodora.vermesan)
Please remember to flip status.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Attachment #818792 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.