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.
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
blocking-fennec1.0: --- → ?
Assignee: nobody → bnicholson
blocking-fennec1.0: ? → +
Priority: -- → P3
Created attachment 606045 [details] [diff] [review] 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.
Attachment #606045 - Flags: review?(mark.finkle)
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.
Attachment #606045 - Flags: review?(mark.finkle) → review+
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 14
status-firefox13: --- → fixed
status-firefox14: --- → fixed
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
Status: RESOLVED → VERIFIED
status-firefox13: fixed → verified
status-firefox14: fixed → verified
You need to log in before you can comment on or make changes to this bug.