Helper dialog and download windows freeze when remote site reports content-type wrongly
Categories
(SeaMonkey :: Download & File Handling, defect)
Tracking
(seamonkey2.49esr wontfix, seamonkey2.53 affected, seamonkey2.57esr affected)
People
(Reporter: buc, Assigned: buc)
Details
Attachments
(4 files, 1 obsolete file)
(deleted),
application/octet-stream
|
Details | |
(deleted),
application/octet-stream
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
iannbugzilla
:
review+
iannbugzilla
:
approval-comm-release+
iannbugzilla
:
approval-comm-esr60+
|
Details | Diff | Splinter Review |
Assignee | ||
Updated•9 years ago
|
Assignee | ||
Updated•9 years ago
|
Assignee | ||
Comment 1•9 years ago
|
||
Comment 2•9 years ago
|
||
Assignee | ||
Comment 3•9 years ago
|
||
Assignee | ||
Comment 4•9 years ago
|
||
Assignee | ||
Comment 5•9 years ago
|
||
Assignee | ||
Comment 6•9 years ago
|
||
Comment 7•9 years ago
|
||
Assignee | ||
Comment 8•8 years ago
|
||
Assignee | ||
Updated•8 years ago
|
Comment 9•8 years ago
|
||
Comment 10•8 years ago
|
||
Assignee | ||
Comment 11•8 years ago
|
||
Comment 12•7 years ago
|
||
Assignee | ||
Comment 13•5 years ago
|
||
Well, no more freeze with 2.53 beta1 .
The behaviour now is exactly as in Firefox-68 -- ie, it reports about "unknown content type" and ask user to choose the right application from a desktop menu (with a possibility to remember such a choise).
OTOH, it seems more friendly for end users to consider file extension (if any) in cases of "unknown or wrong content type", rather than cause them to choose "a right application" when they might know nothing about what to choose.
Anyway, I attach the proposed patch here for future desicions...
Assignee | ||
Comment 14•5 years ago
|
||
The patch against the latest SM 2.53 beta1.
Comment 15•5 years ago
|
||
Trying either SM2.49.5, SM2.53.1 beta 1 or Firefox 71 on Fedora 30, I see no mention of "unknown content type" just "Word 2007 document (3.7kB)" in the dialog.
Where should I see it being reported?
Assignee | ||
Comment 16•5 years ago
|
||
It is "hard to catch", since once seen, the specs appear in ~/.config/mimeapps.list :)
To reproduce, use clear profile and make sure ~/.config/mimeapps.list is (temporary) removed.
Note, standard SM2.49.5 on Fedora 30 has the patch applied. Test with SM2.53.1 and any Firefox .
Comment 18•5 years ago
|
||
As far as I can see there is nothing wrong with the principle of the patch. I've attached a patch against current SM2.53.2
I've tried testing the unpatched application by removing ~/.config/mimeapps.list
tested that:
gio mime application/vnd.openxmlformats
produces:
No default applications for “application/vnd.openxmlformats”
With new profile, SM2.53.1 still picks up the correct LibreOffice Writer (default) and opens successfully.
Assignee | ||
Comment 20•5 years ago
|
||
Well, test with "application/vnd.openxmlformats" was inspired by the actual case, but surely such a type might be included in some distro.
More correct test should use something like "application/foo-bar-nothing" instead.
Comment 21•5 years ago
|
||
Well I tried latest 2.53.2 with CentOS 7 and an older 2.53.1 with Ubuntu 18.04 but no unknown content type.
Assignee | ||
Comment 22•5 years ago
|
||
(In reply to Frank-Rainer Grahl (:frg) from comment #21)
Well I tried latest 2.53.2 with CentOS 7 and an older 2.53.1 with Ubuntu 18.04 but no unknown content type.
Even with "application/foo-bar-nothing" ??
Comment 23•5 years ago
|
||
Even with "application/foo-bar-nothing" ??
No dice on CentOS 7. Didn't change it in Ubuntu.
Updated•5 years ago
|
Description
•