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

VERIFIED FIXED in Firefox 13

Status

()

P3
normal
VERIFIED FIXED
7 years ago
7 years ago

People

(Reporter: emorley, Assigned: bnicholson)

Tracking

Trunk
Firefox 14
ARM
Android
Points:
---

Firefox Tracking Flags

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

Details

(Whiteboard: [MTD])

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
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.
(Reporter)

Updated

7 years ago
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
(Reporter)

Updated

7 years ago
Blocks: 696311
blocking-fennec1.0: --- → ?
Assignee: nobody → bnicholson
blocking-fennec1.0: ? → +
Priority: -- → P3
(Assignee)

Comment 1

7 years ago
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+
https://hg.mozilla.org/mozilla-central/rev/1761ac97c517
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 14
https://hg.mozilla.org/releases/mozilla-aurora/rev/91adf30e7dbe
status-firefox13: --- → fixed
status-firefox14: --- → fixed

Comment 6

7 years ago
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.