Closed Bug 411947 Opened 14 years ago Closed 14 years ago
Download Manager UI not accessed with the ns
IDownload Manager UI everwhere
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008011104 Minefield/3.0b3pre Depending on how I choose to access the download manager UI, it appears in a different location on the screen. If I access the download manager using the CTRL+Y method, it appears on the top-left. If I access the download manager using the Tools>Downloads method, it appears on the top-right. Steps to reproduce: 1. Open Firefox 2. Press CTRL+Y, note the location of the DM UI and close dialog 3. Click Tools>Downloads Actual results: The DM dialog appears in two different locations depending on the access method Expected results: The DM dialog should appear in the same spot, regardless of access method. I will attach a comparative screenshot. Note: drekk(IRC) tested this for me on WinXP. Both access methods display the dialog in the same location.
screenshot is not necessary - I know exactly what you are talking about. Not sure how it's happening though...
This may have been fixed by Bug 412844. Regardless, I see an issue that makes it impossible for an add-on author to override the UI, which was the whole point of the nsIDownloadManagerUI interface....
...and if not, this should do the trick. Note, my currently nightly doesn't exhibit the behavior listed in comment 0.
Assignee: nobody → sdwilsh
Status: NEW → ASSIGNED
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008012504 Minefield/3.0b3pre WFM. Both access methods cause the window to appear in the same location every time now.
Alright, then I'm hijacking this for an issue that I found while investigating this. Requesting blocking because anyone who tries to override nsIDownloadManagerUI won't actually be able to get it to work right with the keyboard shortcut *or* going to Tools->Downloads. This fixes it - I need to test it still, but my tree is hosed, so I'm doing a full rebuild...
OS: Linux → All
Priority: -- → P1
Hardware: PC → All
Summary: Download Manager UI appears in different screen location depending on access method → Download Manager UI not accessed with the nsIDownloadManagerUI everwhere
Target Milestone: --- → Firefox 3 M11
Comment on attachment 299375 [details] [diff] [review] v1.0 OK, tested and it works. yay.
Comment on attachment 299375 [details] [diff] [review] v1.0 r+a=me
This might be testable - I need to think about it a bit more though... Checking in browser/base/content/browser-sets.inc; new revision: 1.110; previous revision: 1.109 Checking in browser/base/content/browser.js; new revision: 1.938; previous revision: 1.937
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
20080126_1335_firefox-3.0b3pre.en-US.win32.zip http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1201381260&maxdate=1201383299 4 DM related checkins. Tools>Download DM window close soon, not stay open.
(In reply to comment #10) > 20080126_1335_firefox-3.0b3pre.en-US.win32.zip > http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1201381260&maxdate=1201383299 > 4 DM related checkins. > > > Tools>Download > > DM window close soon, not stay open. We're tracking this in bug 414214.
memo to myself - in-testsuit? isn't so much for this bug, but more for testing this interface in general.
er, disregard that - this isn't testable in an automated way
Flags: in-testsuite? → in-testsuite-
Both Tools -> Downloads and CTRL+Y open it in the top left position for me, using: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008020504 Minefield/3.0b4pre on: mozilla@mozilla-qa:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 7.10 Release: 7.10 Codename: gutsy Anthony, is this fixed for you?
This seems fixed in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008050904 Minefield/3.0pre
Thanks Al. Verified FIXED also with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050904 Minefield/3.0pre
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.