Fenix: [Bug] download not working on calendar website

[karlcow]

Steps to reproduce

1. go to https://ical.marudot.com/
2. create a calendar entry
3. generate ical (opens a new tab)
4. Download ical file

Expected behavior

save the calendar locally

Actual behavior

The calendar is not saved

Device information

• Android device: Pixel 2 Android 10
• Fenix version: 20200214 (Preview nightly)

see https://webcompat.com/issues/47816 for full details.
This is working on desktop.

Also on mobile the right http requests are being sent.

That's interesting because on mobile it creates the right data and request.

POST /IcalDownload HTTP/1.1
Host: ical.marudot.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:75.0) Gecko/20100101 Firefox/75.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.7,fr-FR;q=0.3
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 95
Origin: https://ical.marudot.com
Connection: keep-alive
Referer: https://ical.marudot.com/pages/result.jsp
Cookie: JSESSIONID=m1urESA_Bo0O33EPGI0Zrg; _ga=GA1.2.294747394.1581916401; _gid=GA1.2.1360524088.1581916401; __gads=ID=6e2803c3a18cfee6:T=1581916401:S=ALNI_MYAVwak86l17kpa48Xo8g53doUQBA; marudot-ical-detail=show; marudot-ical-hour=hour24; marudot-ical-dformat=mdy; marudot-ical-storagetype=local; marudot-ical-track=8-1581916456460; _gat=1
Upgrade-Insecure-Requests: 1

then we get as a response

HTTP/2 200 OK
content-type: text/calendar;charset=UTF-8
content-disposition: attachment;filename=foobar.ics
content-encoding: gzip
x-cloud-trace-context: 549af14cca863a6fb9c702702f4d4259;o=1
vary: Accept-Encoding
date: Mon, 17 Feb 2020 05:34:02 GMT
server: Google Frontend
cache-control: private
content-length: 385
X-Firefox-Spdy: h2

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ical.marudot.com//iCal Event Maker
X-WR-CALNAME:foobar
NAME:foobar
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Asia/Tokyo
TZURL:http://tzurl.org/zoneinfo-outlook/Asia/Tokyo
X-LIC-LOCATION:Asia/Tokyo
BEGIN:STANDARD
TZOFFSETFROM:+0900
TZOFFSETTO:+0900
TZNAME:JST
DTSTART:19700101T000000
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20200217T053402Z
UID:[email protected]
DTSTART;TZID=Asia/Tokyo:20200212T120000
DTEND;TZID=Asia/Tokyo:20200227T120000
SUMMARY:foobar blah blah
DESCRIPTION:foobar
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20200217T053402Z
UID:[email protected]
DTSTART;TZID=Asia/Tokyo:20200227T120000
DTEND;TZID=Asia/Tokyo:20200227T120000
SUMMARY:foobar blah blah
DESCRIPTION:foobar
END:VEVENT
END:VCALENDAR

but somehow this was not saved locally, even with

content-type: text/calendar;charset=UTF-8
content-disposition: attachment;filename=foobar.ics
content-encoding: gzip

[vdng9338]

Firefox Nightly seems to handle POST downloads incorrectly. When debugging the main process, I can see that a valid POST request is made to ical.marudot.com first, but clicking the Download button makes Firefox send a second GET request instead, which does not work. The same issue can be reproduced on http://concours-maths-cpge.fr for instance (this website relies solely on POST requests, which means I cannot download any file from it).

[tenzap]

Still present in Firefox v80.1.3
But apparently fixed in Nightly v201012 17:02

I also had the same issue in Opera Mini & DuckDuckgo browser (but not in chrome)

[Amejia481]

QA please help us to verify if this issue is reproducible in Nightly, thanks in advance :)

[tenzap]

Did you read what I wrote ? ;)

[Amejia481]

@tenzap thanks :)
Before closing an issue, we ask the QA team to double check, as they have a large set of devices with different OS versions. This way we reduce the possibility that the issue is still reproducible :)

[tenzap]

ok, thanks for clarifying :D

[ebalazs-sv]

@Amejia481 I had tested this on Nightly 201015 (Build #2015769771) GV 83.0a1 from 10/15 with Pixel 2 (Android 9) and the iCal File is downloaded.
This issue is still reproducible on Beta 82.0.0-beta.4 GV 82.0 from 10/6 and RC 81.1.4 GV 81.0.1 from 10/8.
I will remove the qa:needed label.

[Amejia481]

I think we can close this as it already fixed on nightly, please feel free to reopen if needed.