Closed Bug 856202 Opened 11 years ago Closed 11 years ago

Defect - can't download nightly full installer


(Firefox for Metro Graveyard :: General, defect, P1)



(firefox21 unaffected, firefox22+ verified, firefox23+ verified, b2g18+ affected)

Firefox 23
Tracking Status
firefox21 --- unaffected
firefox22 + verified
firefox23 + verified
b2g18 + affected


(Reporter: jbecerra, Assigned: bbondy)



(Keywords: regression, Whiteboard: feature=defect c=Downloads_app_bar u=metro_firefox_user p=2)


(1 file, 2 obsolete files)

While testing 850415 I noticed that I couldn't find the nightly full installer after downloading it. After a second look it may not be downloading the file. It certainly isn't listed in the Downloads page.

I tried downloading other files like this video, and that worked:

I also tried some PDF publications from the IRS which open up in the page, but are also downloaded as PDF documents which you can find with the Search charm.

The search charm doesn't list the full installer, and the Downloads folder for the user doesn't have it.

Desktop Firefox has no problem downloading these files.

1. Go to
2. Tap on the Windows (Standard) download link
3. Tap on the download bar to start the download
- At this point there should be an item for this installer download, but there isn't any.
4. Swipe to show the Search charm and look for "installer" in the files category.

Expected: You should get a result.

Actual: Nothing found.

You can also try the stub installers or the linux installers, but that also doesn't seem to work.

This might be a dupe of 852014.
Blocks: metrov1it6
Summary: defect - can't download nightly full installer → Defect - can't download nightly full installer
Whiteboard: feature=defect c=tbd u=tbd p=tbd
Marco this is pretty close to the work I'm doing in it5 for bug 852014.  Do you mind if I take this during it5 while doing that work?
Blocks: 801136
Whiteboard: feature=defect c=tbd u=tbd p=tbd → feature=defect c=tbd u=tbd p=2
> This might be a dupe of 852014.

Agreed it might be, but not completely sure yet until I investigate more.
Hey Brian, no problem.  I'll move Bug 856202 over to Iteration #5.
Assignee: nobody → netzen
Blocks: metrov1it5
No longer blocks: metrov1it6
Priority: -- → P1
QA Contact: jbecerra
Whiteboard: feature=defect c=tbd u=tbd p=2 → feature=defect c=Downloads_app_bar u=metro_firefox_user p=2
Attached patch Patch v1. (obsolete) — Splinter Review
What's happening is that nsAlertService.cpp's ShouldShowAlert returns false because we're in immersive mode.  
When ShouldShowAlert returns false it sends out a "alertfinished" event and we cancel the download right away.
See: to see us canceling.
See: to see us sending the alertfinished because we're in immersive mode.

I first tried to fix this by detecting immersive mode in SHQueryUserNotificationState and returning true in ShouldShowAlert.
But this falls through to "rv = mXULAlerts.ShowAlertNotification" which hangs the browser.

Since we provide our own custom alert service we already call into it here and it succeeds:
I'm not sure why we don't always return there on all platforms when it succeeds but we have a couple different implementations of that (b2g, linux, possibly more) and I don't want to cause regressions in there.

So to fix this I return on success of our own alert service code.
Attachment #733549 - Flags: review?(jmathies)
This is not a dupe of bug 852014 by the way.
This bug has to do with the popup that comes up when trying to download an installer that asks you to tap to download, and the tap not working (because of auto cancel)
Is this behavior triggered because it's an executable?
no not in particular, any type that has no mime default, see the else clause to this condition here:
To summarize the toolkit code is always firing "alertfinished" right away in Metro and it shouldn't even reach that code in metro.
and we watch for "alertfinished" and cancel from front end code.
Comment on attachment 733549 [details] [diff] [review]
Patch v1.

discussed on irc, r+ as a work around. bbondy is going to file a follow up on the code that landed in bug 699014, which doesn't look right.
Attachment #733549 - Flags: review?(jmathies) → review+
***code that landed in bug 782211 caused the regression
Attached patch Patch v2. (obsolete) — Splinter Review
I'm pretty sure this is just a regression introduced in bug 782211 so going ahead with the fix for all platforms. Looks like B2G is the only other one that is affected by this.
Attachment #733549 - Attachment is obsolete: true
Attachment #733596 - Flags: review?(doug.turner)
I'll update the patch to r=dougt before pushing after it is reviewed by the way.
Blocks: 782211
Keywords: regression
Likely causes problems on b2g since it is the only other platform that implements its own sysAlerts.
since this is on b2g v22 not sure if you wanted to track or not
Attachment #733596 - Flags: review?(doug.turner) → review?(wchen)
Attachment #733596 - Flags: review?(wchen) → review+
Attached patch Patch v3.Splinter Review
Attachment #733596 - Attachment is obsolete: true
Attachment #734769 - Flags: review?(wchen)
Attachment #734769 - Flags: review?(wchen) → review+
Closed: 11 years ago
Resolution: --- → FIXED
Flags: needinfo?(mozbugs.retornam)
Verified fixed  on April 10th, 2013  built from

The downloaded items are shown on the Downloads tab and can be found using  the search charm.
Flags: needinfo?(mozbugs.retornam)
Doug - do you think we need this on m-b2g18? If so, can you mark as blocking-b2g:tef? or approval-mozilla-b2g18:?
Flags: needinfo?(doug.turner)
Doug - Basically any kind of alert (based on my reading of the code) *should* show the b2g sysalerts followed by an xul alert.  But I haven't tested this, I'm just going by what I think the code does on b2g.
brian's right -- this should be uplifted everywhere.
Flags: needinfo?(doug.turner)
Comment on attachment 734769 [details] [diff] [review]
Patch v3.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 782211 
User impact if declined:  Some B2G notifications might be double prompting or prompting once and then and error happening.
Testing completed (on m-c, etc.): It's been on m-c for a while
Risk to taking this patch (and alternatives if risky): Low
String or IDL/UUID changes made by this patch: None.
Attachment #734769 - Flags: approval-mozilla-aurora?
If is impacted, please mark this bug as blocking-b2g:leo?
Attachment #734769 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(In reply to Alex Keybl [:akeybl] from comment #24)
> If is impacted, please mark
> this bug as blocking-b2g:leo?

It doesn't look like it but the bug that introduced this looks like it is tracking b2g18 so it may in the future. You may want to also track this one for it.
Tracking flag is because the bug that introduced the bug (bug 782211) is marked for tracking b2g18 already.
tracking-b2g18: --- → ?
Blocks: 850415
Verified with 22, 23, 24 and 25 nighty builds.
The full installers are downloaded correctly and shown in the Downloads tab. They can also be found using search charm.
You need to log in before you can comment on or make changes to this bug.