Last Comment Bug 1256074 - Always present a 'search' option when the location bar search is "fixed" to an URL
: Always present a 'search' option when the location bar search is "fixed" to a...
Status: VERIFIED FIXED
[fxsearch]
:
Product: Firefox
Classification: Client Software
Component: Location Bar (show other bugs)
: unspecified
: Unspecified Unspecified
P2 normal with 3 votes (vote)
: Firefox 52
Assigned To: Evan Tseng [:evanxd]
:
: Marco Bonardo [::mak]
Mentors:
https://www.reddit.com/r/firefox/comm...
: 1282367 (view as bug list)
Depends on:
Blocks: 1071461 1080682 1262507
  Show dependency treegraph
 
Reported: 2016-03-12 19:04 PST by Wes Kocher (:KWierso)
Modified: 2017-02-01 06:32 PST (History)
15 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard: [testday-20161021]
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
verified

MozReview Requests
Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:
Show discarded requests

Attachments
bug-1256074.patch (1.08 KB, patch)
2016-08-25 02:55 PDT, Evan Tseng [:evanxd]
no flags Details | Diff | Splinter Review
bug-1256074.patch (1.52 KB, patch)
2016-09-06 20:26 PDT, Evan Tseng [:evanxd]
shorlander: ui‑review+
mak77: feedback+
Details | Diff | Splinter Review
Bug 1256074 - Always present a 'search' option when the location bar search is "fixed" to an URL. (58 bytes, text/x-review-board-request)
2016-10-05 20:11 PDT, Evan Tseng [:evanxd]
mak77: review+
Details | Review

Description User image Wes Kocher (:KWierso) 2016-03-12 19:04:50 PST
If I type "http.listenandserve" into the location bar, the only action shown is to "Visit http://http.listenandserve/" because it was detected as a URL to visit, but I wanted to search for "http.listenandserve" to find out how to use it.  

It'd be nice if there was still an option listed to search for "http.listenandserve" with my default engine, at least if the string after the '.' isn't detected as a common tld.
Comment 1 User image Guillaume C. [:ge3k0s] 2016-04-16 08:32:31 PDT
This would really be helpful to better match other browsers behavior. AFAICT Firefox is the only one that doesn't provide URL search in the Awesomebar. It would also remove one big disadvantage disabling the search bar (only way to search an URL currently).
Comment 2 User image Marco Bonardo [::mak] 2016-04-18 08:15:27 PDT
I agree, we should evaluate this.

Stephen, what do you think? When we offer to visit something that looks like a domain, should we also offer to search for it ina separate entry? Would that take up too much space (in the end when typing a domain it's less likely for the user to search for something deeper, indeed we do "to the next slash" autofill)
Did you have ideas about alternative approaches to solve the same problem?
Comment 3 User image Daniel N. 2016-04-26 15:59:22 PDT
Thank you for taking this into consideration! I was the guy asking the question on reddit and Wes was kind enough to create a bug for it. 
The main problem for me is not that Firefox doesn't allow to search for URLs, but that it recognizes everything with a dot in it as an URL. The "http.ListenAndServe" example is a function from golang's http library. A visit option should probably not even be there. Maybe an easy solution would be to test against the list of valid TLDs and show search or visit options based on that? Searching the 1300 valid TLDs should be very fast, a lot quicker than the bookmark search that is already happening.
Comment 4 User image arni2033 2016-08-03 01:28:24 PDT
I think the last time _I_ reported this, it was pretty much considered and rejected by Marco
in bug 1080682.

*** This bug has been marked as a duplicate of bug 1198832 ***
Comment 5 User image Marco Bonardo [::mak] 2016-08-03 01:32:42 PDT
not exactly a dupe, I still think we should keep this as a fall back, since I'm not sure bug 1080682 can easily be done.
I don't think I rejected the idea, I think I only expressed some concerns. Otherwise, maybe I was just wrong.
Comment 6 User image arni2033 2016-08-03 01:39:25 PDT
(In reply to Marco Bonardo [::mak] (Away 6-20 Aug) from comment #5)
> not exactly a dupe, I still think we should keep this as a fall back, since
> I'm not sure bug 1080682 can easily be done.
I never said that this is duplicate of bug 1080682.
I know that _this_ is duplicate my _open_ bug 1198832 filed long time ago with explanation.
Comment 7 User image Marco Bonardo [::mak] 2016-08-03 01:42:07 PDT
*** Bug 1198832 has been marked as a duplicate of this bug. ***
Comment 8 User image Marco Bonardo [::mak] 2016-08-03 01:44:06 PDT
(In reply to arni2033 from comment #6)
> I never said that this is duplicate of bug 1080682.
> I know that _this_ is duplicate my _open_ bug 1198832 filed long time ago
> with explanation.

We don't duplicate bugs based on filed date, it's mostly based on usefulness of the contained comments. The original duplication there made sense cause the only solution was to use the PSL. This bug suggests a different solution, so honestly the duplication was correct. But just in case I updated all the dependencies.
Comment 9 User image Marco Bonardo [::mak] 2016-08-03 06:59:42 PDT
*** Bug 1282367 has been marked as a duplicate of this bug. ***
Comment 10 User image Evan Tseng [:evanxd] 2016-08-20 01:05:38 PDT
Hi Marco,

Look like we need to add two `richlistitem` elements(moz-action:visiturl and moz-action:searchengine ones)[1] on the `#PopupAutoCompleteRichResult` panel when the `moz-action` is `visiturl` to fix the issue.

I would like to give it a shot.

[1]: https://github.com/mozilla/gecko-dev/blob/master/toolkit/content/widgets/autocomplete.xml#L1220
Comment 11 User image Evan Tseng [:evanxd] 2016-08-20 01:10:59 PDT
But look like we also need UX input here to ensure(always present a `search` option) the behavior is what we want.

Hi Stephen,

How do you think of Comment 2 Marco mentioned?

> Stephen, what do you think? When we offer to visit something that looks like
> a domain, should we also offer to search for it ina separate entry? Would
> that take up too much space (in the end when typing a domain it's less
> likely for the user to search for something deeper, indeed we do "to the
> next slash" autofill)
> Did you have ideas about alternative approaches to solve the same problem?
Comment 12 User image Marco Bonardo [::mak] 2016-08-24 07:32:07 PDT
(In reply to Evan Tseng [:evanxd][:愛聞插低] from comment #10)
> Look like we need to add two `richlistitem` elements(moz-action:visiturl and
> moz-action:searchengine ones)[1] on the `#PopupAutoCompleteRichResult` panel
> when the `moz-action` is `visiturl` to fix the issue.

I think it will be enough to do some changes to UnifiedComplete.js, we don't want a UI hack like showing/hiding boxes for this.
Comment 13 User image Evan Tseng [:evanxd] 2016-08-25 02:55:51 PDT
Created attachment 8784759 [details] [diff] [review]
bug-1256074.patch

Hi Stephen,

Could you review the UI change[1]?

In the video[1], when an user inputs `node.js` keyword, the URL bar will give search `node.js` option not only `visiturl` option. It enhances UX.

And if you're using Mac OS, you can download the build[2] and use it.

What do you think of the UI change?

[1]: https://youtu.be/6q8ZKEufvUI
[2]: https://drive.google.com/open?id=0B3MxK4_nj3bpUEw3eElHeFBjWHM
Comment 14 User image Evan Tseng [:evanxd] 2016-08-25 02:59:18 PDT
Comment on attachment 8784759 [details] [diff] [review]
bug-1256074.patch

Hi Marco,

Thanks for the suggestions in Comment 12. It's so helpful to write the patch.

Could you give feedback for it?

Thanks.
Comment 15 User image Marco Bonardo [::mak] 2016-08-26 09:52:10 PDT
Comment on attachment 8784759 [details] [diff] [review]
bug-1256074.patch

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

::: toolkit/components/places/UnifiedComplete.js
@@ +1328,5 @@
>      }
>  
>      this._addMatch(match);
> +    // Always add a `searchengine` match.
> +    yield this._matchCurrentSearchEngine();

I'd probably do this at the calling point, to avoid mixing up the code, so where we do:

 let matched = yield this._matchUnknownUrl();
      if (matched) {
======> here
        return;

Also, I think this deserves a larger comment briefly explaining why we also want to add a searchengine match that boils down to something like: "Since we can't tell if this is a real url and whether the user wanted to visit or search for it, we always provide an alternative searchengine match."

Finally, I don't think we should provide a search option if we didn't "fix" what was typed. Basically, if the user typed a valid URI (scheme//domain/path) it's very unlikely he needs to search for it. The cases where search is needed is when something LOOKS LIKE a uri and we "fix" it to be an uri.
That could be done by checking if new URL(this._originalSearchString) throws. it's a little bit more expensive, but it's only done when _matchUnknownUrl returns true...
Comment 16 User image Evan Tseng [:evanxd] 2016-09-06 20:26:49 PDT
Created attachment 8788726 [details] [diff] [review]
bug-1256074.patch

Updated the patch for feedbacks in Comment 15.
Comment 17 User image Evan Tseng [:evanxd] 2016-09-06 21:01:14 PDT
Comment on attachment 8788726 [details] [diff] [review]
bug-1256074.patch

Hi Marco,

Updated the patch for your comments.
Thanks for the review and clear comments.

Please help review it.
Thanks.


The try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=bfa7b19965ff
Comment 18 User image Evan Tseng [:evanxd] 2016-09-06 23:28:08 PDT
Comment on attachment 8788726 [details] [diff] [review]
bug-1256074.patch

Hi Stephen,

Could you review the UI change[1]?

In the video[1], when an user inputs `node.js` keyword, the URL bar will give search `node.js` option not only `visiturl` option. It enhances UX.

You can download the below builds to try the UI changes.
Mac OS: https://archive.mozilla.org/pub/firefox/try-builds/itoyxd@gmail.com-bfa7b19965ffc3f5f29a3aa69fdba9fcb807de84/try-macosx64/
Linux: https://archive.mozilla.org/pub/firefox/try-builds/itoyxd@gmail.com-bfa7b19965ffc3f5f29a3aa69fdba9fcb807de84/try-linux64/
Windows: https://archive.mozilla.org/pub/firefox/try-builds/itoyxd@gmail.com-bfa7b19965ffc3f5f29a3aa69fdba9fcb807de84/try-win64/

What do you think of the UI change?

[1]: https://youtu.be/6q8ZKEufvUI
[2]: https://drive.google.com/open?id=0B3MxK4_nj3bpUEw3eElHeFBjWHM
Comment 19 User image Evan Tseng [:evanxd] 2016-09-06 23:34:19 PDT
Hi Philipp,

Let me answer the question here.

> To confirm: this would NOT happen for known TLDs like .com .net .de and the like right?
> If the item would also show up for TLDs like those, I would consider that a blocking issue.

Yes, if the search keyword is a valid URI(scheme//domain/path), just like Marco mentioned in Comment 15.
Comment 20 User image bintoro 2016-09-07 00:48:47 PDT
(In reply to Evan Tseng [:evanxd][:愛聞插低] from comment #19)
> > To confirm: this would NOT happen for known TLDs like .com .net .de and the like right?
> > If the item would also show up for TLDs like those, I would consider that a blocking issue.
> 
> Yes, if the search keyword is a valid URI(scheme//domain/path) [...]

I don't think people type in the scheme most of the time. If it's considered undesirable to show the search option for known valid hosts, excluding only complete URIs will not accomplish that. Rather, we should see if the host is in the browsing history.

I was under the impression that that's how this was going to work, but now I'm no longer sure.

To illustrate, assume I've never visited Reddit. Upon typing in "reddit.com" for the first time, the default action would be "Visit", and the secondary action would be "Search". On subsequent occasions, "Search" would no longer be displayed, as "www.reddit.com" is in the history. Correct? No?

And note I said "host". If http://kb.mozillazine.org/Browser.urlbar.match.url is found in my history, it doesn't mean I'd like to visit http://urlbar.match.url when I type in "urlbar.match.url" again.
Comment 21 User image Marco Bonardo [::mak] 2016-09-07 00:53:54 PDT
Note we are still waiting for UX to evaluate this, so let's not go too far into discussions for now :)

The fact is Nightly already has a way to do this, through one-off buttons, you can just type whatever and use the default engine one-off search button. So this workaround would only be needed until we get one-off buttons in Release. That makes all of this very much depending on the fate and timing of that feature.
Comment 22 User image bintoro 2016-09-07 01:02:03 PDT
Wait, this feature is going to be a temporary workaround? But there are already at least two perfectly fine workarounds:

* Prefix a single or double quote -- example: 'node.js
* Use the shortcut to your preferred search engine -- example: g node.js
Comment 23 User image Marco Bonardo [::mak] 2016-09-07 01:16:38 PDT
those are not discoverable. Btw, I'm just saying there's no point in going too deep into discussing this until we get ux feedback.
Comment 24 User image Stephen Horlander [:shorlander] 2016-09-13 12:10:40 PDT
The one-off search buttons would fix this by providing a persistent way to always search. But given that this is a pretty specific use-case elevating the search option into the list, even though it creates a slight redundancy, seems worth it.
Comment 25 User image Evan Tseng [:evanxd] 2016-09-19 01:12:16 PDT
(In reply to Stephen Horlander [:shorlander] from comment #24)
> The one-off search buttons would fix this by providing a persistent way to
> always search. But given that this is a pretty specific use-case elevating
> the search option into the list, even though it creates a slight redundancy,
> seems worth it.

Hi Stephen,

Looks like you agree with that (Comment 19) show search option when the search keyword is a valid URI(scheme//domain/path), right? If so, could you set the "ui-review"(Comment 18) flag as "ui-review+" for the patch? Or you could continue to review it with the video[1] or using the builds[2].

Thanks.

[1]: https://youtu.be/6q8ZKEufvUI
[2]: https://treeherder.mozilla.org/#/jobs?repo=try&revision=bfa7b19965ff
Comment 26 User image Stephen Horlander [:shorlander] 2016-09-21 12:41:43 PDT
Comment on attachment 8788726 [details] [diff] [review]
bug-1256074.patch

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

Looks good to me. Thanks!
Comment 27 User image Marco Bonardo [::mak] 2016-09-23 07:54:59 PDT
Comment on attachment 8788726 [details] [diff] [review]
bug-1256074.patch

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

The patch looks good to me, but we really want some kind of automated test.
The test should live in toolkit/components/places/tests/unifiedcomplete, and I actually think you could just modify test_visiturl.js
Indeed, I suspect that test may already be failing with this change, cause it's expecting one result and getting 2 now.

You should run the tests in that subfolder with ./mach test toolkit/components/places/tests/unifiedcomplete to be sure
we clearly need something that fails without the patch and passes with it, if modifying existing tests is enough, that be it, otherwise you'll have to add a further subtest.

Finally, I'm actually thinking some things could not really want a search option, for example strings containing a "/" or valid ips are unlikely to be searched. I guess in addition to the url check we may want a regexp like !/(.*\..*){3,}|[\[\/]/.test(_originalSearchString) (no more than 2 dots, no / and no [)
Comment 28 User image Panos Astithas [:past] 2016-09-26 05:14:37 PDT
It's useful to sometimes use the awesomebar as a calculator. In those cases I might type 23.5/3.324 or (567*987)/6 expecting the search engine to get back with a result. Can't we be more lenient with this kind of input?
Comment 29 User image Marco Bonardo [::mak] 2016-09-26 05:22:27 PDT
(In reply to Panos Astithas [:past] from comment #28)
> It's useful to sometimes use the awesomebar as a calculator. In those cases
> I might type 23.5/3.324 or (567*987)/6 expecting the search engine to get
> back with a result. Can't we be more lenient with this kind of input?

those are not valid urls, indeed if you type them in the awesomebar you get a search entry, not a visit entry.
The option here is added only for strings that URI Fixup *thinks* are urls (so we show a visit entry for them).
Comment 30 User image Panos Astithas [:past] 2016-09-26 05:42:30 PDT
Excellent, carry on then!
Comment 31 User image Evan Tseng [:evanxd] 2016-10-05 03:19:39 PDT
Marco, thanks for the comments. Pushed a new try for fixing the tests: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f302c052744b06b90d68cb5ca124d06b4d905a86
Comment 32 User image Evan Tseng [:evanxd] 2016-10-05 20:11:34 PDT Comment hidden (mozreview-request)
Comment 33 User image Evan Tseng [:evanxd] 2016-10-05 20:15:16 PDT
Pushed a new try for the review: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7dc4910909149d3ace6bbce695a4734bd8d4d655
Comment 34 User image Marco Bonardo [::mak] 2016-10-07 09:04:28 PDT
Comment on attachment 8798290 [details]
Bug 1256074 - Always present a 'search' option when the location bar search is "fixed" to an URL.

https://reviewboard.mozilla.org/r/83810/#review82834

It looks good! I'd say we are almost there, just a couple details.

::: toolkit/components/places/UnifiedComplete.js:1007
(Diff revision 1)
> +        try {
> +          new URL(this._originalSearchString);
> +        } catch (ex) {
> +          // Show search option if keyword.enabled is true
> +          // and the string doesn't contain more than 2 dots, [, or /.
> +          if (Prefs.keywordEnabled && !/(.*\..*){3,}|[\[\/]/.test(this._originalSearchString)) {

please move the regexp to a const at the top like we did with REGEXP_SPACES or REGEXP_USER_CONTEXT_ID. So we don't have to rebuild it every time.

::: toolkit/components/places/tests/unifiedcomplete/test_searchSuggestions.js:482
(Diff revision 1)
>    yield check_autocomplete({
>      search: "localhost",
>      searchParam: "enable-actions",
>      matches: [
>        makeVisitMatch("localhost", "http://localhost/", { heuristic: true }),
> +      makeSearchMatch("localhost", { engineName: ENGINE_NAME, heuristic: true })

ok, this is a problem, this is not exactly an heuristic result based on how we consider it.

What you should do is: this._addingHeuristicFirstMatch = false;
yield this._matchCurrentSearchEngine();
this._addingHeuristicFirstMatch = true;

and update the tests showing it as heuristic

::: toolkit/components/places/tests/unifiedcomplete/test_visiturl.js:60
(Diff revision 1)
>    yield check_autocomplete({
>      search: "about:config",
>      searchParam: "enable-actions",
> -    matches: [ { uri: makeActionURI("visiturl", {url: "about:config", input: "about:config"}), title: "about:config", style: [ "action", "visiturl", "heuristic" ] } ]
> +    matches: [
> +      { uri: makeActionURI("visiturl", {url: "about:config", input: "about:config"}), title: "about:config", style: [ "action", "visiturl", "heuristic" ] },
> +      { uri: makeActionURI("searchengine", {engineName: "MozSearch", input: "about:config", searchQuery: "about:config"}), title: "MozSearch", style: ["action", "searchengine", "heuristic"] }

HM, right, about:something...
I think for now we may want to also add ":" to the list of blacklisted chars, for the protocol:something case

And again, remember to update tests accordingly.
Comment 35 User image Evan Tseng [:evanxd] 2016-10-12 00:53:02 PDT Comment hidden (mozreview-request)
Comment 36 User image Evan Tseng [:evanxd] 2016-10-12 01:00:07 PDT
Hi Marco,

I updated the patch and tests(all passed in local).
Please help review it, thanks.

The try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1238e5538337adcb9324f57ce62b23b0a7641289
Comment 37 User image Marco Bonardo [::mak] 2016-10-17 07:55:04 PDT
Comment on attachment 8798290 [details]
Bug 1256074 - Always present a 'search' option when the location bar search is "fixed" to an URL.

https://reviewboard.mozilla.org/r/83810/#review85084

I'm sorry for that, but you likely need to unbitrot the tests, cause I added some new testcases to them in a different bug.
I think this will be the last roundtrip, then the patch should be landable.

::: toolkit/components/places/UnifiedComplete.js:85
(Diff revision 2)
>  
>  // Regex used to match one or more whitespace.
>  const REGEXP_SPACES = /\s+/;
>  
> +// Regex used to match URL.
> +const REGEXP_URL = /(.*\..*){3,}|[\[\/\:]/;

this doesn't exactly match a url, rather something that may look like an url-
I'd name it REGEXP_LOOKSLIKEURL. But actually...
...I'd love if we could reuse looksLikeUrl function for this, so maybe we could modify it like this:

function looksLikeUrl(str, ignoreAlphanumericHosts = false) {
  // Single word not including special chars.
  return !REGEXP_SPACES.test(str) &&
         ["/", "@", ":", "["].some(c => str.includes(c)) &&
         (ignoreAlphanumericHosts ? /(.*\..*){3,}/.test(str) : str.includes("."));
}
(note I replaced . with [ in the includes check)

and then our new code could use !looksLikeUrl(this._originalSearchString, true);

::: toolkit/components/places/UnifiedComplete.js:1004
(Diff revision 2)
>        // but isn't in the whitelist.
>        let matched = yield this._matchUnknownUrl();
>        if (matched) {
> +        // Since we can't tell if this is a real URL and
> +        // whether the user wants to visit or search for it,
> +        // we always provide an alternative searchengine match.

s/always/may/
Comment 38 User image Marco Bonardo [::mak] 2016-10-17 07:56:36 PDT
or the argument may be named "ignoreSingleDottedHosts", I couldn't come up with a better name, but it's not critical.
Comment 39 User image Evan Tseng [:evanxd] 2016-10-18 02:25:27 PDT
I think `looksLikeUrl` is OK.
Comment 40 User image Evan Tseng [:evanxd] 2016-10-18 02:27:52 PDT Comment hidden (mozreview-request)
Comment 41 User image Evan Tseng [:evanxd] 2016-10-18 02:32:43 PDT
Hi Marco,

I've updated the patch for your comments. Please review it again.

The try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=162b0a732c1f4c32a38710d682252a9c495b233f

Thanks.
Comment 42 User image Marco Bonardo [::mak] 2016-10-18 09:39:16 PDT
Comment on attachment 8798290 [details]
Bug 1256074 - Always present a 'search' option when the location bar search is "fixed" to an URL.

https://reviewboard.mozilla.org/r/83810/#review85616

it looks good! thank you
Comment 43 User image Marco Bonardo [::mak] 2016-10-18 09:39:51 PDT
jsut one small note, please update the commit message to the current bug title since it's clearer
Comment 44 User image Evan Tseng [:evanxd] 2016-10-18 20:06:57 PDT Comment hidden (mozreview-request)
Comment 45 User image Evan Tseng [:evanxd] 2016-10-18 20:17:37 PDT
I've updated the commit message.

Wait for that the try[1] is good, and then let's do `checkin-needed`.

Thanks for review, Marco.

[1]: https://treeherder.mozilla.org/#/jobs?repo=try&revision=162b0a732c1f4c32a38710d682252a9c495b233f
Comment 46 User image Evan Tseng [:evanxd] 2016-10-18 20:57:03 PDT
The try is good. Let's checkin-needed.
Comment 47 User image Ryan VanderMeulen [:RyanVM] 2016-10-19 19:48:37 PDT
Please mark the pending issues in MozReview as resolved so that this can autoland.
Comment 48 User image Evan Tseng [:evanxd] 2016-10-20 01:18:34 PDT
Hi Ryan,

I've resolved the issues, but I don't have LV3. Still need checkin-needed here.

Thanks.
Comment 49 User image Marco Bonardo [::mak] 2016-10-20 01:39:22 PDT
in theory you should be able to autoland if you got review from someone having LV3, like me.
That said, I just pressed the button for you.
Comment 50 User image Pulsebot 2016-10-20 01:39:29 PDT
Pushed by mak77@bonardo.net:
https://hg.mozilla.org/integration/autoland/rev/bb8d2847640f
Always present a 'search' option when the location bar search is "fixed" to an URL. r=mak
Comment 51 User image Evan Tseng [:evanxd] 2016-10-20 02:35:13 PDT
Thanks, Mark.

I don't why my "Land Commits" button is still disabled after you r+ the patch.
Comment 52 User image Carsten Book [:Tomcat] 2016-10-20 07:50:16 PDT
https://hg.mozilla.org/mozilla-central/rev/bb8d2847640f
Comment 53 User image Saheda Reza [:Antora] 2016-10-23 02:52:55 PDT
I have reproduced this bug on firefox nightly according to(2016-03-12)

Fixing bug is verified on Latest Nightly -- Build ID:( 20161022030204 ),User Agent: Mozilla/5.0 (Windows NT 10.0; rv:52.0) Gecko/20100101 Firefox/52.0

Tested OS-- Windows10 32bit
Comment 54 User image Maruf Rahman[:mMARUF] 2017-01-20 00:46:29 PST
I have reproduced this bug with Nightly 48.0a1 on Ubuntu 16.04 LTS!

This bug's fix is verified with latest Developer Edition (Aurora)!

Build   ID  :  20170119004006
User Agent  :  Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

[testday-20170120]
Comment 55 User image Panos Astithas [:past] 2017-01-20 06:46:18 PST
Thanks!
Comment 56 User image surentharan14 2017-02-01 06:32:57 PST
[bugday-20170201]

Note You need to log in before you can comment on or make changes to this bug.