Closed Bug 732818 Opened 12 years ago Closed 12 years ago

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


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



(firefox13 verified, firefox14 verified, blocking-fennec1.0 +)

Firefox 14
Tracking Status
firefox13 --- verified
firefox14 --- verified
blocking-fennec1.0 --- +


(Reporter: emorley, Assigned: bnicholson)



(Whiteboard: [MTD])


(1 file)

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

1) Navigate to
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:

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 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.
Summary: Page URL cleared when giving the awesomebar focus, after using "open link in new tab" on downloads → Current URL not shown when awesomebar tapped, after using "open link in new tab" on downloads
Blocks: 696311
blocking-fennec1.0: --- → ?
Assignee: nobody → bnicholson
blocking-fennec1.0: ? → +
Priority: -- → P3
Attached patch patchSplinter Review
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.
Attachment #606045 - Flags: review?(mark.finkle)
Comment on attachment 606045 [details] [diff] [review]

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:

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.
Attachment #606045 - Flags: review?(mark.finkle) → review+
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 14
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
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.