732818 - Current URL not shown when awesomebar tapped, after using "open link in new tab" on downloads

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect, P3)

Description

[Ed Morley [:emorley]]

Galaxy S2, Android 2.3.4, Fennec Native Nightly 13.0a1 2012-03-04

1) Navigate to http://nightly.mozilla.org
2) Long press the download Android APK link, and choose "open link in new tab"
3) Switch to the newly opened tab, tap in the awesomebar in order to give it focus and so you can trim:
"http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-mozilla-central-android/fennec-13.0a1.en-US.android-arm.apk"
to
"http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/"

Expected results:
* The file URL that can be seen in the awesomebar, prior to giving it focus, is still present after giving focus, so the string edit can be performed.

Actual results:
* After giving the awesomebar focus, the string changes to the "Enter Search or Address" placeholder, and no actual text is present in the textbox.
* Ie: what bug 696311 implemented isn't occurring if the new tab was opened for a download.


Use Case:
* Since there is no "copy link location" feature (pending bug 718437), opening in a new tab and then editing the existing URL in the awesomebar, is the only way to go to http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/ without typing it in manually.
* On desktop, file downloads opened in new tabs correctly populate the awesomebar with a string that can be user edited.

Comment 1

[Brian Nicholson (:bnicholson)]

Attachment: patch

I don't know why we look at history instead of just calling tab.getURL() for the AwesomeBar URL, but it broke this case because we don't add downloads to history. tab.getURL() works fine.

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 606045 [details] [diff] [review]
patch

We probably don't add the download to history because we don't ever load any page. Note that we set the Tab.mUrl in the constructor, but we don't add a HistoryEntry until we call Tab.updateUrl(...) in handleLocationChange.

Your patch should be OK.

Looking at Desktop, they have a function to set the text in the URLBar here:
http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#2547

It uses the "userTyped" value first, then falls back to the browser.currentURI (which is what our HistoryEntry mimics).

Did we add a way to keep the "userTyped", or "userEntered", value? Maybe we should think of using that one as well. That might be the fix for bug 709451 so we could do the work in that bug.

Comment 3

[Brian Nicholson (:bnicholson)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/1761ac97c517

Comment 4

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/1761ac97c517

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/91adf30e7dbe

Comment 6

[Paul Feher]

Verified/fixed on:

Aurora Fennec 13.0a2 (2012-03-27)
Nightly Fennec 14.0a1 (2012-03-27)
Device: Samsung Nexus S
OS: Android 2.3.6