Closed Bug 1349797 Opened 7 years ago Closed 7 years ago

Domain autocompletion is case-sensitive

Categories

(Firefox for Android Graveyard :: Awesomescreen, defect, P2)

Product:
Firefox for Android Graveyard
Component:
Awesomescreen
Platform:
All
Android
Type:
defect

Tracking

(fennec+, firefox55 wontfix, firefox56 wontfix, firefox57 verified)

Status:
VERIFIED FIXED
Milestone:
Firefox 57
Tracking Flags:
Tracking Status
fennec + ---
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- verified

People

(Reporter: ahunt, Assigned: mehdisolamannejad, Mentored)

References

Details

(Whiteboard: [good next bug][lang=java])

Attachments

(1 file, 2 obsolete files)

Bug 1349797 - Make domain autocompletion case-insensitive.
59 bytes, text/x-review-board-request
JanH
: review+
Details 
STR:
1. Click on URL bar
2. Type "G"

Expected: autocomplete to "Google.com" shown
Actual: no autocomplete

This probably requires making our domain autocomplete case insensitive, see:
https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/home/BrowserSearch.java?q=path%3ABrowserSearch.java&redirect_type=single#586

See a potential approach to fixing this from Focus:
https://github.com/mozilla-mobile/focus-android/commit/b7cb81b21c4bf1aaca66a8446a1f6e4f75c71fea
Hi, I just joined this site and am looking for a first bug to fix to get my feet wet. Can I work on this bug?
(In reply to Benjamin De Brasi from comment #1)
> Hi, I just joined this site and am looking for a first bug to fix to get my
> feet wet. Can I work on this bug?

Hi Benjamin,

Sure! Do you have a build of Firefox for Android yet? If not, I'd recommend taking a look at our build guide:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_for_Android_build

Feel free to join us on IRC on #mobile (see https://wiki.mozilla.org/IRC ) if you need help getting a build (we try to make the build as simple as possible, but sometimes it can be tricky), or if you have any questions regarding the code.
Hi, Is this bug still unassigned? I am also a newb in search for a good first bug to fix, and would be happy to work on it.
(In reply to vaibhav singh from comment #3)
> Hi, Is this bug still unassigned? I am also a newb in search for a good
> first bug to fix, and would be happy to work on it.

I think Benjamin was looking into this last week, I'm not sure what the current status there is. I'd recommend getting a build configured as a first step (see comment #2), and if Benjamin isn't back by then feel free to take over this bug!
Hello,

I am part of a group at my University taking part in an Open Source course. I see that a couple of people have taken an interest in this bug, but there has not been any further activity for a week. Is this bug up for grabs again? My group has expressed an interest in working on it for our first assignment.

Thank you, in advance, for any assistance!

-Stephen
Sorry for the late response. I actually over estimated the amount of time I have given that it's the tail end of the semester. If anyone wants to take this bug that's completely fine with me. If no one has picked this up after my finals I'll dig into it.
I know my group is still very much interested in taking on this bug for our first bug for our class. We have a development environment ready to go per the linked instructions in comment 2.
Hi Stephen: sure, you are welcome to take this bug! If you have any questions feel free to ask here, or you can also ask questions on our IRC channel (#mobile on irc.mozilla.org, see https://wiki.mozilla.org/IRC )!
Andrzej, thank you, consider my group on the case. We will be sure to check out the channel.
Hello. I want to submit a possible fix for Bug 1349797. Can you help me how to do it? I have tried it on my phone. Its working good now.
I didnt see that Stephen and his team started working on it. So, if they haven't submitted there fix yet then can you look into my fix?
tracking-fennec: --- → ?
Sourabh, 

My team has decided to gracefully get out of the way since you have a fix already.

Cheers!
-Stephen
triage:
P2, tracking+
tracking-fennec: ? → +
Priority: -- → P2
I am trying to work on this bug. I guess we need to change findAutocompletion() function according to one described in Focus or should we create a new function itself for Auto Completion?
Flags: needinfo?(andrzej)
(In reply to Owais Kazi from comment #14)
> I am trying to work on this bug. I guess we need to change
> findAutocompletion() function according to one described in Focus or should
> we create a new function itself for Auto Completion?

I actually created a helper function just as in the focus. You can try it to. 
P.S.: I actually solved the issue but I had to wipe my system and I have no backup code.
Attachment #8878685 - Flags: review?(andrzej)
Hello, I am a newbie and I want to work on this bug to get started. If this hasn't been assigned to anyone yet or there are any further amendments to be made, please let me know.
Comment on attachment 8878685 [details] [diff] [review]
Make domain autocomplete case insensitive

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

Sorry for the delay, but Andrzej isn't around at the moment. In any case the solution isn't quite as simple as in Focus, because we're also searching the user's history.

A solution could be to add case insensitive versions of startsWith (implemented along the lines of https://stackoverflow.com/a/38947571) in StringUtils (https://dxr.mozilla.org/mozilla-central/source/mobile/android/geckoview/src/main/java/org/mozilla/gecko/util/StringUtils.java) and then use that in BrowserSearch (not just in searchDomains, but also in findAutocompletions, too). Our code that then takes this suggestion and compares it with the input entered by the user in ToolbarEditText also needs changing likewise (https://dxr.mozilla.org/mozilla-central/rev/8486950bd91878bf077a9ac33cb3c018288fe518/mobile/android/base/java/org/mozilla/gecko/toolbar/ToolbarEditText.java#293 - the calls to TextUtils.regionMatches there effectively do a startsWith check).
Attachment #8878685 - Flags: review?(andrzej)
Mentor: andrzej → jh+bugzilla
status-firefox55: affected → ---
Keywords: good-first-bug
OS: Unspecified → Android
Hardware: Unspecified → All
Whiteboard: [good next bug][lang=java]
Hey.
Can you please assign this bug to me? This is my first bug, but I'm confident I can work it out.
If you've got a build environment set up, feel free to submit a patch whenever you're ready - we'll sort the formal assigning out then.
(In reply to Jan Henning [:JanH] from comment #20)
> If you've got a build environment set up, feel free to submit a patch
> whenever you're ready - we'll sort the formal assigning out then.

Done. What's the next step?
That was quick :-), and I see you've also managed to go through Mozreview, great.

(In reply to mehdisolamannejad from comment #22)
> Done. What's the next step?

Whoever you've asked to review the patch (in this case me) takes a look at the patch to see whether it's okay to land or if there are any outstanding issues with it. If there are any issues, you need to respond to them and/or submit a new version of your patch as required.

Once the reviewer is happy with your changes (meaning your patch gets an r+) and the patch doesn't break our automated tests, you can edit the bug to set the "checkin-needed" keyword, after which the patch will be merged into our main repository.

Before the review proper, just two small requests:
- Can you please leave out the whitespace/formatting changes out of your main commit? Including them makes it harder to see the actual meaningful code changes to fix this bug.
- Your second commit message (Bug 1349797 - Make domain autocompletion case-insensitive) is fine, but can you please merge the two commits together and resubmit the result to Mozreview? It's always a good idea to split large patches into smaller parts that build upon each other, but fix-up/WIP/... commits and the like should always be folded together.
Assignee: nobody → mehdisolamannejad
Attachment #8890370 - Attachment is obsolete: true
Attachment #8890370 - Flags: review?(jh+bugzilla)
(In reply to Jan Henning [:JanH] from comment #24)
> That was quick :-), and I see you've also managed to go through Mozreview,
> great.
> 
> (In reply to mehdisolamannejad from comment #22)
> > Done. What's the next step?
> 
> Whoever you've asked to review the patch (in this case me) takes a look at
> the patch to see whether it's okay to land or if there are any outstanding
> issues with it. If there are any issues, you need to respond to them and/or
> submit a new version of your patch as required.
> 
> Once the reviewer is happy with your changes (meaning your patch gets an r+)
> and the patch doesn't break our automated tests, you can edit the bug to set
> the "checkin-needed" keyword, after which the patch will be merged into our
> main repository.
> 
> Before the review proper, just two small requests:
> - Can you please leave out the whitespace/formatting changes out of your
> main commit? Including them makes it harder to see the actual meaningful
> code changes to fix this bug.
> - Your second commit message (Bug 1349797 - Make domain autocompletion
> case-insensitive) is fine, but can you please merge the two commits together
> and resubmit the result to Mozreview? It's always a good idea to split large
> patches into smaller parts that build upon each other, but fix-up/WIP/...
> commits and the like should always be folded together.

Thanks for the help.

1. It's just a habit of mine to casually use Ctrl+Alt+L to format the code in IntelliJ IDEA. It was only after the push I realized it messed up the indentation. So that's why I pushed again in hopes of it being merged automatically with the previous commit.

2. Done.

Waiting for you to review :D
Comment on attachment 8890360 [details]
Bug 1349797 - Make domain autocompletion case-insensitive.

https://reviewboard.mozilla.org/r/161476/#review167452

Save for some minor comments, the logic itself is fine. There still are a number of formatting changes that shouldn't be there, though. While cleaning up files is always appreciated, I'd rather leave any instances of purposefully done manual indentation aöpme, even if it unfortunately ends up clashing with the IDE's automatic indentation.
As for other style/whitespace fixes and the like, you can include them as tag-alongs if you're touching the files anyway, but it's good practice to split them into a separate cleanup commit, so the change history remains clearer about which changes were really necessary to fix the actual bug.

::: mobile/android/base/java/org/mozilla/gecko/home/BrowserSearch.java:85
(Diff revision 2)
>  
>  /**
>   * Fragment that displays frecency search results in a ListView.
>   */
>  public class BrowserSearch extends HomeFragment
> -                           implements BundleEventListener,
> +        implements BundleEventListener,

Whitespace change that shouldn't be here.

::: mobile/android/base/java/org/mozilla/gecko/home/BrowserSearch.java:315
(Diff revision 2)
>      @Override
>      public void onDestroyView() {
>          super.onDestroyView();
>  
>          EventDispatcher.getInstance().unregisterUiThreadListener(this,
> -            "SearchEngines:Data");
> +                "SearchEngines:Data");

Whitespace change, ditto.

::: mobile/android/base/java/org/mozilla/gecko/home/BrowserSearch.java:420
(Diff revision 2)
>          final boolean isPrivate = (tab != null && tab.isPrivate());
>          mList.setPrivateMode(isPrivate);
>  
>          registerForContextMenu(mList);
>          EventDispatcher.getInstance().registerUiThreadListener(this,
> -            "SearchEngines:Data");
> +                "SearchEngines:Data");

Whitespace change, ditto.

::: mobile/android/base/java/org/mozilla/gecko/home/BrowserSearch.java:506
(Diff revision 2)
>          SearchLoader.init(getLoaderManager(), LOADER_ID_SEARCH, mCursorLoaderCallbacks, mSearchTerm);
>      }
>  
>      private void handleAutocomplete(String searchTerm, Cursor c) {
>          if (c == null ||
> -            mAutocompleteHandler == null ||
> +                mAutocompleteHandler == null ||

Whitespace change, ditto.

::: mobile/android/base/java/org/mozilla/gecko/home/BrowserSearch.java:1118
(Diff revision 2)
>          private static final int ROW_STANDARD = 1;
>          private static final int ROW_SUGGEST = 2;
>  
>          public SearchAdapter(Context context) {
>              super(context, null, new int[] { ROW_STANDARD,
> -                                             ROW_SEARCH,
> +                            ROW_SEARCH,

Whitespace change, ditto.

::: mobile/android/base/java/org/mozilla/gecko/home/BrowserSearch.java:1308
(Diff revision 2)
>              setSavedSuggestions(new ArrayList<String>());
>          }
>      }
>  
>      private static class ListSelectionListener implements View.OnFocusChangeListener,
> -                                                          AdapterView.OnItemSelectedListener {
> +            AdapterView.OnItemSelectedListener {

Whitespace change, ditto.

::: mobile/android/base/java/org/mozilla/gecko/toolbar/ToolbarEditText.java:41
(Diff revision 2)
>  import android.view.inputmethod.InputMethodManager;
>  import android.view.accessibility.AccessibilityEvent;
>  import android.widget.TextView;
>  
>  /**
> -* {@code ToolbarEditText} is the text entry used when the toolbar
> + * {@code ToolbarEditText} is the text entry used when the toolbar

Whitespace change, although unlike other changes which are debatable this would indeed be nice to fix. If you really want to include this, split it out into a separate cleanup commit.

::: mobile/android/base/java/org/mozilla/gecko/toolbar/ToolbarEditText.java:46
(Diff revision 2)
> -* {@code ToolbarEditText} is the text entry used when the toolbar
> + * {@code ToolbarEditText} is the text entry used when the toolbar
> -* is in edit state. It handles all the necessary input method machinery.
> + * is in edit state. It handles all the necessary input method machinery.
> -* It's meant to be owned by {@code ToolbarEditLayout}.
> + * It's meant to be owned by {@code ToolbarEditLayout}.
> -*/
> + */
>  public class ToolbarEditText extends CustomEditText
> -                             implements AutocompleteHandler {
> +        implements AutocompleteHandler {

Whitespace change that shouldn't be here.

::: mobile/android/base/java/org/mozilla/gecko/toolbar/ToolbarEditText.java:125
(Diff revision 2)
>          try {
>              imm.restartInput(this);
>              imm.hideSoftInputFromWindow(getWindowToken(), 0);
>          } catch (NullPointerException e) {
>              Log.e(LOGTAG, "InputMethodManagerService, why are you throwing"
> -                          + " a NullPointerException? See bug 782096", e);
> +                    + " a NullPointerException? See bug 782096", e);

Whitespace change, ditto.

::: mobile/android/base/java/org/mozilla/gecko/toolbar/ToolbarEditText.java:153
(Diff revision 2)
>      public void sendAccessibilityEventUnchecked(AccessibilityEvent event) {
>          // We need to bypass the isShown() check in the default implementation
>          // for TYPE_VIEW_TEXT_SELECTION_CHANGED events so that accessibility
>          // services could detect a url change.
>          if (event.getEventType() == AccessibilityEvent.TYPE_VIEW_TEXT_SELECTION_CHANGED &&
> -            getParent() != null && !isShown()) {
> +                getParent() != null && !isShown()) {

Whitespace change, ditto.

::: mobile/android/base/java/org/mozilla/gecko/toolbar/ToolbarEditText.java:188
(Diff revision 2)
>      /**
>       * Reset autocomplete states to their initial values
>       */
>      private void resetAutocompleteState() {
>          mAutoCompleteSpans = new Object[] {
> -            // Span to mark the autocomplete text
> +                // Span to mark the autocomplete text

Whitespace change, ditto.

::: mobile/android/base/java/org/mozilla/gecko/toolbar/ToolbarEditText.java:316
(Diff revision 2)
>          if (autoCompleteStart > -1) {
>              // Autocomplete text already exists; we should replace existing autocomplete text.
>  
>              // If the result and the current text don't have the same prefixes,
>              // the result is stale and we should wait for the another result to come in.
> -            if (!TextUtils.regionMatches(result, 0, text, 0, autoCompleteStart)) {
> +            if(!StringUtils.caseInsensitiveStartsWith(result.substring(0, autoCompleteStart),

There's no need to trim `result` here - this is already implied by the fact that you're doing a `startsWith`-type check.

Also, if you look at your `caseInsensitiveStartsWith` implementation, you'll notice that it uses the second argument's length as the length paramter for `String.regionMatches()`. Since you're trimming `text` to `autoCompleteStart`, this means that the length ends up as `autoCompleteStart`, just like in the current call to TextUtils.

::: mobile/android/base/java/org/mozilla/gecko/toolbar/ToolbarEditText.java:317
(Diff revision 2)
>              // Autocomplete text already exists; we should replace existing autocomplete text.
>  
>              // If the result and the current text don't have the same prefixes,
>              // the result is stale and we should wait for the another result to come in.
> -            if (!TextUtils.regionMatches(result, 0, text, 0, autoCompleteStart)) {
> +            if(!StringUtils.caseInsensitiveStartsWith(result.substring(0, autoCompleteStart),
> +                    text.toString().substring(0, autoCompleteStart))) {

Doing the trimming in a local variable beforehand (like `final String userText = ...`) could improve readability.

::: mobile/android/base/java/org/mozilla/gecko/toolbar/ToolbarEditText.java:456
(Diff revision 2)
>                  final int composingStart = BaseInputConnection.getComposingSpanStart(editable);
>                  final int composingEnd = BaseInputConnection.getComposingSpanEnd(editable);
>                  // We only delete the autocomplete text when the user is backspacing,
>                  // i.e. when the composing text is getting shorter.
>                  if (composingStart >= 0 &&
> -                    composingEnd >= 0 &&
> +                        composingEnd >= 0 &&

Whitespace change, ditto.

::: mobile/android/base/java/org/mozilla/gecko/toolbar/ToolbarEditText.java:627
(Diff revision 2)
>  
>                  return true;
>              }
>  
>              if ((keyCode == KeyEvent.KEYCODE_DEL ||
> -                (keyCode == KeyEvent.KEYCODE_FORWARD_DEL)) &&
> +                    (keyCode == KeyEvent.KEYCODE_FORWARD_DEL)) &&

Whitespace change, ditto.

::: mobile/android/geckoview/src/main/java/org/mozilla/gecko/util/StringUtils.java:75
(Diff revision 2)
>  
>      /**
>       * Strip the ref from a URL, if present
>       *
>       * @return The base URL, without the ref. The original String is returned if it has no ref,
> -     *         of if the input is malformed.
> +     * of if the input is malformed.

Whitespace change. If you want, you can fix the typo, though and put it in the cleanup commit.

::: mobile/android/geckoview/src/main/java/org/mozilla/gecko/util/StringUtils.java:216
(Diff revision 2)
>       * Given a url with a user-entered scheme, extract the
>       * scheme-specific component. For e.g, given "user-entered://www.google.com",
>       * this method returns "//www.google.com". If the passed url
>       * does not have a user-entered scheme, the same url will be returned.
>       *
> -     * @param  url to be decoded
> +     * @param url to be decoded

Whitespace change, ditto.

::: mobile/android/geckoview/src/main/java/org/mozilla/gecko/util/StringUtils.java:233
(Diff revision 2)
>          return Uri.fromParts("user-entered", url, null).toString();
>      }
>  
>      /**
>       * Compatibility layer for API < 11.
> -     *
> +     * <p>

Other unrelated formatting changes.

::: mobile/android/geckoview/src/main/java/org/mozilla/gecko/util/StringUtils.java:280
(Diff revision 2)
>  
>          return "\u200E" + text;
>      }
> +
> +    /**
> +     * Returns true if 'text' starts with 'prefix', with no case sensitivity

If you're writing a one-line that starts with "Returns", you can directly write `@return True if ...` instead. Or as an alternative suggestion e.g. just use `Case insensitive version of {@link String#startsWith(String)}.`

::: mobile/android/geckoview/src/main/java/org/mozilla/gecko/util/StringUtils.java:287
(Diff revision 2)
> +    public static boolean caseInsensitiveStartsWith(String text, String prefix) {
> +        return caseInsensitiveStartsWith(text, prefix, 0);
> +    }
> +
> +    /**
> +     * Returns true if 'text' from index 'start' starts with 'prefix', with no case sensitivity

Ditto. Either make this `@return True if ...`, or as an alternative suggestion e.g. `Case insensitive version of Case insensitive version of {@link String#startsWith(String, int)}.`
Attachment #8878685 - Attachment is obsolete: true
Comment on attachment 8890360 [details]
Bug 1349797 - Make domain autocompletion case-insensitive.

Hm, didn't clear via Mozreview, so doing it manually.
Attachment #8890360 - Flags: review?(jh+bugzilla)
(In reply to Jan Henning [:JanH] from comment #27)
> Comment on attachment 8890360 [details]
> Bug 1349797 - Make domain autocompletion case-insensitive.
> 
> https://reviewboard.mozilla.org/r/161476/#review167452
> 
> Save for some minor comments, the logic itself is fine. There still are a
> number of formatting changes that shouldn't be there, though. While cleaning
> up files is always appreciated, I'd rather leave any instances of
> purposefully done manual indentation aöpme, even if it unfortunately ends up
> clashing with the IDE's automatic indentation.
> As for other style/whitespace fixes and the like, you can include them as
> tag-alongs if you're touching the files anyway, but it's good practice to
> split them into a separate cleanup commit, so the change history remains
> clearer about which changes were really necessary to fix the actual bug.

Sorry (again) for the whitespaces. It was done automatically by IntelliJ when I copied the code back. Used gedit this time.

And thanks for pointing out the mistakes.

Waiting for you to review again.
Comment on attachment 8890360 [details]
Bug 1349797 - Make domain autocompletion case-insensitive.

https://reviewboard.mozilla.org/r/161476/#review167968

Almost there, although one important line apparently got lost between patch versions.

When you go submit a new patch version, remember to also go through the previous review (e. g. https://reviewboard.mozilla.org/r/161476/#review167452) and mark all issues that you adressed either "fixed" or "dropped", as applicable. In case you disagree with a review comment or have further questions, you can write reply there. Also, before the patch can land through Mozreview, all issues need to be marked as handled anyway.

::: mobile/android/base/java/org/mozilla/gecko/toolbar/ToolbarEditText.java:340
(Diff revision 3)
>              // No autocomplete text yet; we should add autocomplete text
>  
>              // If the result prefix doesn't match the current text,
>              // the result is stale and we should wait for the another result to come in.
>              if (resultLength <= textLength ||
>                      !TextUtils.regionMatches(result, 0, text, 0, textLength)) {

The change here somehow got lost between patch versions, so your patch won't work if e.g. the first letter you type is uppercase.

::: mobile/android/geckoview/src/main/java/org/mozilla/gecko/util/StringUtils.java:279
(Diff revision 3)
>              return text;
>          }
>  
>          return "\u200E" + text;
>      }
> +    /**

missing newline

::: mobile/android/geckoview/src/main/java/org/mozilla/gecko/util/StringUtils.java:293
(Diff revision 3)
> +     */
> +    public static boolean caseInsensitiveStartsWith(String text, String prefix, int start) {
> +        return text.regionMatches(true, start, prefix, 0, prefix.length());
> -}
> +    }
> +}
> +

... and on newline too many
Attachment #8890360 - Flags: review?(jh+bugzilla)
(In reply to Jan Henning [:JanH] from comment #31)
> Comment on attachment 8890360 [details]
> Bug 1349797 - Make domain autocompletion case-insensitive.
> 
> https://reviewboard.mozilla.org/r/161476/#review167968
> 
> Almost there, although one important line apparently got lost between patch
> versions.
> 
> When you go submit a new patch version, remember to also go through the
> previous review (e. g.
> https://reviewboard.mozilla.org/r/161476/#review167452) and mark all issues
> that you adressed either "fixed" or "dropped", as applicable. In case you
> disagree with a review comment or have further questions, you can write
> reply there. Also, before the patch can land through Mozreview, all issues
> need to be marked as handled anyway.

Oh, done. Thanks.
Comment on attachment 8890360 [details]
Bug 1349797 - Make domain autocompletion case-insensitive.

https://reviewboard.mozilla.org/r/161476/#review168100

There's no need to completely ditch the IDE by the way - in my experience as long as you don't hit the Auto-Indent Lines option, Android Studio normally only changes statements you're touching anyway and so should be pretty safe to use - besides you can always use hg commit --interactive respectively git add --patch to only commit the changes you want and either revert everything else or move it into a separate cleanup commit.

::: mobile/android/base/java/org/mozilla/gecko/toolbar/ToolbarEditText.java:340
(Diff revisions 3 - 4)
>              // No autocomplete text yet; we should add autocomplete text
>  
>              // If the result prefix doesn't match the current text,
>              // the result is stale and we should wait for the another result to come in.
>              if (resultLength <= textLength ||
> -                    !TextUtils.regionMatches(result, 0, text, 0, textLength)) {
> +                    !StringUtils.caseInsensitiveStartsWith(result, text.toString()) {

[Syntax error](https://treeherder.mozilla.org/logviewer.html#?job_id=119287054&repo=try&lineNumber=23553) when you attempt to [build this](https://treeherder.mozilla.org/#/jobs?repo=try&revision=1829b01031ef852262458bab5f99cc9e99c8e237&selectedJob=119287054).
Attachment #8890360 - Flags: review?(jh+bugzilla)
Comment on attachment 8890360 [details]
Bug 1349797 - Make domain autocompletion case-insensitive.

https://reviewboard.mozilla.org/r/161476/#review168100

> [Syntax error](https://treeherder.mozilla.org/logviewer.html#?job_id=119287054&repo=try&lineNumber=23553) when you attempt to [build this](https://treeherder.mozilla.org/#/jobs?repo=try&revision=1829b01031ef852262458bab5f99cc9e99c8e237&selectedJob=119287054).

so sorry about this. Should be more careful from now on.
Comment on attachment 8890360 [details]
Bug 1349797 - Make domain autocompletion case-insensitive.

https://reviewboard.mozilla.org/r/161476/#review168406

If [this test run](https://treeherder.mozilla.org/#/jobs?repo=try&revision=9973d42cf7064e48eaef1997d3d2b50916dd5098) doesn't throw up anything unexpected, you're good to go.
Attachment #8890360 - Flags: review?(jh+bugzilla) → review+
Keywords: checkin-needed
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/2c9acb1b3235
Make domain autocompletion case-insensitive. r=JanH
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/2c9acb1b3235
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox57: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
Should we nominate this for Beta56 approval or let it ride the 57 train?
status-firefox55: --- → wontfix
status-firefox56: --- → affected
Flags: needinfo?(andrzej) → needinfo?(jh+bugzilla)
I'd let it ride to have more time for some potential follow-up work (bug 1388112).
status-firefox56: affected → wontfix
Flags: needinfo?(jh+bugzilla)
Blocks: 1388112
Verified as fixed in Beta 57.0b3.
Devices:
Asus ZenPad 8.0 Z380KL (Android 6.0.1)
LG G4 (Android 6.0)
Lenovo A536 (Android 4.4.2)
Status: RESOLVED → VERIFIED
status-firefox57: fixed → verified
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: