Defect - can't download nightly full installer

VERIFIED FIXED in Firefox 22

Status

P1
normal
VERIFIED FIXED
6 years ago
9 months ago

People

(Reporter: jbecerra, Assigned: bbondy)

Tracking

({regression})

Trunk
Firefox 23
x86
Mac OS X
regression
Dependency tree / graph

Firefox Tracking Flags

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

Details

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

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

6 years ago
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: http://www.blueskyfootage.com/Video_Formats/#format3

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.

STR:
1. Go to nightly.mozilla.org
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.

Updated

6 years ago
Blocks: 855905
Summary: defect - can't download nightly full installer → Defect - can't download nightly full installer
Whiteboard: feature=defect c=tbd u=tbd p=tbd
(Assignee)

Comment 1

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

Comment 2

6 years ago
> 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: 850809
No longer blocks: 855905
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

Updated

6 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 4

6 years ago
Created attachment 733549 [details] [diff] [review]
Patch v1.

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: http://dxr.mozilla.org/mozilla-central/browser/metro/components/HelperAppDialog.js#l44 to see us canceling.
See: http://dxr.mozilla.org/mozilla-central/toolkit/components/alerts/nsAlertsService.cpp#l105 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:
http://dxr.mozilla.org/mozilla-central/toolkit/components/alerts/nsAlertsService.cpp#l99
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)
(Assignee)

Comment 5

6 years ago
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)

Comment 6

6 years ago
Is this behavior triggered because it's an executable?
(Assignee)

Comment 7

6 years ago
no not in particular, any type that has no mime default, see the else clause to this condition here:
http://dxr.mozilla.org/mozilla-central/browser/metro/components/HelperAppDialog.js#l28
(Assignee)

Comment 8

6 years ago
To summarize the toolkit code is always firing "alertfinished" right away in Metro and it shouldn't even reach that code in metro.
(Assignee)

Comment 9

6 years ago
and we watch for "alertfinished" and cancel from front end code.

Comment 10

6 years ago
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+
(Assignee)

Comment 11

6 years ago
***code that landed in bug 782211 caused the regression
(Assignee)

Comment 12

6 years ago
Created attachment 733596 [details] [diff] [review]
Patch v2.

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)
(Assignee)

Comment 13

6 years ago
I'll update the patch to r=dougt before pushing after it is reviewed by the way.
(Assignee)

Updated

6 years ago
Blocks: 782211
Keywords: regression
(Assignee)

Comment 14

6 years ago
Likely causes problems on b2g since it is the only other platform that implements its own sysAlerts.
(Assignee)

Comment 15

6 years ago
since this is on b2g v22 not sure if you wanted to track or not
tracking-firefox22: --- → ?

Updated

6 years ago
Attachment #733596 - Flags: review?(doug.turner) → review?(wchen)

Updated

6 years ago
Attachment #733596 - Flags: review?(wchen) → review+
(Assignee)

Comment 16

6 years ago
Created attachment 734769 [details] [diff] [review]
Patch v3.
Attachment #733596 - Attachment is obsolete: true
Attachment #734769 - Flags: review?(wchen)

Updated

6 years ago
Attachment #734769 - Flags: review?(wchen) → review+
https://hg.mozilla.org/mozilla-central/rev/f49cb7d4b736
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Updated

6 years ago
Flags: needinfo?(mozbugs.retornam)
Verified fixed  on April 10th, 2013  built from http://hg.mozilla.org/mozilla-central/rev/9db46ddfb517

The downloaded items are shown on the Downloads tab and can be found using  the search charm.
Status: RESOLVED → VERIFIED
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:?
tracking-firefox22: ? → ---
Flags: needinfo?(doug.turner)
(Assignee)

Comment 21

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

Updated

6 years ago
status-firefox22: --- → ?
(Assignee)

Comment 23

6 years ago
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 https://hg.mozilla.org/releases/mozilla-b2g18/ is impacted, please mark this bug as blocking-b2g:leo?
status-firefox21: --- → unaffected
status-firefox22: ? → affected
status-firefox23: --- → affected
tracking-firefox22: --- → +
tracking-firefox23: --- → +

Updated

6 years ago
Attachment #734769 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Updated

6 years ago
status-firefox23: affected → fixed
(Assignee)

Comment 26

6 years ago
(In reply to Alex Keybl [:akeybl] from comment #24)
> If https://hg.mozilla.org/releases/mozilla-b2g18/ 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.
(Assignee)

Comment 27

6 years ago
Tracking flag is because the bug that introduced the bug (bug 782211) is marked for tracking b2g18 already.
tracking-b2g18: --- → ?
status-b2g18: --- → affected
tracking-b2g18: ? → +

Updated

5 years ago
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.
status-firefox22: fixed → verified
status-firefox23: fixed → verified
You need to log in before you can comment on or make changes to this bug.