858021 - Awesomebar blank if Firefox window was opened by link in 3rd-party software

Status: RESOLVED INACTIVE

(Firefox :: Address Bar, defect)

Description

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Tested on OS X 10.8.3 with 23.0a1 (2013-04-03). Bug reproduced all times tested.

1. Launch Nightly, close immediately the window leaving the process running in background
2. start another app, for instance Thunderbird or a twitter client, an app where you can activate http links that will open Nightly
3. find such a link and click it to open a Nightly window

EXPECTED RESULT: window opens with requested URL, URL appears in awesomebar
ACTUAL RESULT:   window opens with requested URL, awesomebar remains blank

This bug is really VERY annoying from a user's perspective. I would recommend
making it a blocker for next FF release.

Comment 1

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Ah, more info: this is for the *first tab* of the window only.
Similarly, the following is probably another symptom of the bug already reported above:

1. launch Nightly, close window immediately
2. copy the following URL into clipboard

   http://www.w3.org/mid/CAAWBYDBXKY2Nbch=hrRYVLzTztn_4qvR9tvhHEcHobmYUi0G=[e-mail]

3. open Nightly window clicking on its icon in Dock
4. paste URL in awesomebar, hit return

EXPECTED RESULT: content loads, awesomebar shows http://lists.w3.org/Archives/Public/www-style/2013Apr/0064.html
ACTUAL RESULT:   content loads, URL unchanged in awesomebar

Comment 2

[Marco Bonardo [:mak]]

I suppose we would need some QA checks before being able to tell if should be tracked, but regardless setting the request won't hurt.

Comment 3

[Ada [:adalucinet]]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Firefox/21.0

I've reproduced this issue using steps from comment 0 with Nightly from 2013-04-03 (20130403030841): the awesome bar is always blank when I open links from another app (thunderbird, skype). The same behavior is on the latest Nightly (20130417031053) and latest Aurora (20130417004018), FF 19 (20130326150557), FF 20.0.1 (20130409194949) and FF 4.0 (20110318052756), 	
therefore this issue is not a regression. 

Although, I wasn't able to reproduce using steps from comment 1: the awesome bar shows the correct url (http://lists.w3.org/Archives/Public/www-style/2013Apr/0064.html).

Comment 4

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to Alexandra Lucinet [QA] from comment #3)

> Although, I wasn't able to reproduce using steps from comment 1: the awesome
> bar shows the correct url
> (http://lists.w3.org/Archives/Public/www-style/2013Apr/0064.html).

I just updated Nightly on OS X and now have 23.0a1 (2013-04-17). The issue 
reported in comment 1 is still here, sorry.

Comment 5

[Lukas Blakk [:lsblakk] use ?needinfo]

Given this repros all the way back to FF4, it's not a valid tracking bug for FF23.

Comment 6

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.