Closed Bug 1111540 Opened 7 years ago Closed 7 years ago

Nightly 37/Win64: About:Preferences#Applications does not allow to set an application for a content type, keeps 'Always ask

Categories

(Firefox :: Preferences, defect, P1)

37 Branch
All
Windows 7
defect
Points:
5

Tracking

()

VERIFIED FIXED
Firefox 38
Iteration:
38.2 - 9 Feb
Tracking Status
firefox38 --- verified

People

(Reporter: zxspectrum3579, Assigned: Gijs)

References

Details

(Keywords: regression)

Attachments

(3 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20141214030205

Steps to reproduce:

1. Open About:Preferences#Applications,
2. Try to select a concrete application to process "application/torrent" content type: open pull-down menu, select "Use other...", select concrete application (BitComet -- a BitTorrent Client)



Actual results:

Nothing happens, the setting/value keeps to be "Always ask", even though there were not error messages (see the attached screen shot), "OK" was accepted just fine.


Expected results:

Instead of showing "Always ask" as incorrectly happens now, the settings should turn into "Use BitComet -- a BitTorrent client (default)" (just as it is set now one line below, for "application/x-torrent" content type -- see the attached screen shot).
Component: Untriaged → File Handling
OS: Windows 7 → Other
Hardware: x86 → x86_64
OS: Other → Windows 7
Are you able to clik and display the drop-down list about actions for the "application/torrent" content type?
Is it stuck to "Always ask"?
Flags: needinfo?(zxspectrum3579)
Loic, I am perfectly able to select "Use other..." from pull-down menu and further select concrete application by click on "OK" in a dialogue window about that.

However, whatever actions I take, they are ignored and the value always stays "Always ask".
Flags: needinfo?(zxspectrum3579)
Hi User Dderss asked me in bug 1106396 to check why in his profile(he provided me a profile for debugging bug 1106396) downloading a torrent file does not open torrent application. 

Clicking on a torrent file, using nightly 20141218030202, no files are downloaded and looking at the log it even does not start a connection, no necko channel is open.
In a clean profile it works as it should.
I think it is addon related and in About:Preferences#Applications there are: application/torrent and application/x-torrent.

I need to say that the problem above maybe is related, I do not know.
Sorry, I made a mistake... let me try again:

(In reply to User Dderss from comment #2)
> Loic, I am perfectly able to select "Use other..." from pull-down menu and
> further select concrete application by click on "OK" in a dialogue window
> about that.
> 
> However, whatever actions I take, they are ignored and the value always
> stays "Always ask".

If you go into your profile (Help > Troubleshooting Information, click the button next to "Profile Folder), then close Firefox completely, then move the * mimeTypes.rdf * file to mimeTypes-old.rdf, and then restart Firefox, and then change some of the preferences (you probably have to download another torrent file for the torrents to show up in the Applications list), does that fix it?
Thanks, Gijs, I know if I just wipe it, things will will work (many people have torrent mime), the question is why FireFox butchers it and does not even realize it. If the browser can not update this file without messing its structure -- at least at times -- should not it have built-in XML validator to understand that the file is corrupt?
Flags: needinfo?(zxspectrum3579)
(In reply to User Dderss from comment #6)
> Thanks, Gijs, I know if I just wipe it, things will will work (many people
> have torrent mime), the question is why FireFox butchers it and does not
> even realize it. If the browser can not update this file without messing its
> structure -- at least at times -- should not it have built-in XML validator
> to understand that the file is corrupt?

It would be great if we could do this - but in practice, I've never had mine be corrupt, and have no idea what causes it. Are there any errors when you change things in that dialog and we try to write the file? (In the browser console -- tools > web developer > browser console; best clear it before, then do something that should write to the file, then see if there's new messages) If you've got a corrupt file, would you be willing to share it? :-)
Blocks: 1042394
Flags: needinfo?(zxspectrum3579)
Summary: Nightly 37/Win64: About:Preferences#Applications does not allow to set an application for a content type, keeps 'Always ask' → Detect and fix corrupted mimeTypes.rdf files
Attached file mimeTypes.rdf.old
This is quite big 47 KB messy mime type file. I have not seen errors in the console when I tried to make changes. Everything is smooth, but it is just not getting updated. If you will put this file instead of yours in your session, you can try to repeat my actions and see if things will work. Dragana has tried my whole profile, she replicated result. FireFox at least should track that user wanted to make change, and if after the file recreated and re-read anew that change user wanted to make did not happen, it had to be aware of it and generate some sort of error (at least internal, and maybe send corrupted file for data analysis).
Flags: needinfo?(zxspectrum3579)
Attachment #8546750 - Attachment mime type: application/x-trash → application/xml
Odd, it's valid XML. I'll try to have a look next week. :-\
Flags: needinfo?(gijskruitbosch+bugs)
You can search for "torrent" and see the difference between "application/torrent" and "application/x-torrent".
My diagnosis was just wrong; I can't change any mime type to a different application on any of my profiles. :-|

Seems like this is broken, but not just in e10s mode. Still looking at this further.
No longer blocks: 1042394
Component: File Handling → Preferences
Summary: Detect and fix corrupted mimeTypes.rdf files → Nightly 37/Win64: About:Preferences#Applications does not allow to set an application for a content type, keeps 'Always ask
This works in the windowed preferences, but not in in-content prefs.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(gijskruitbosch+bugs)
This is because:

http://hg.mozilla.org/mozilla-central/annotate/643589c3ef94/browser/components/preferences/in-content/applications.js#l1719

assumes that the dialog open code is sync an will only return after an app has been picked (which is what it does on Windows non-in-content prefs). This is no longer the case in the in-content prefs. The windows code there probably needs to be in the unload handler for the subdialog or something like that.
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Iteration: --- → 38.1 - 26 Jan
Points: --- → 5
Flags: qe-verify+
Flags: in-testsuite?
Flags: firefox-backlog+
Hardware: x86_64 → All
I'm sure there is a dupe of this bug where I replied previously... but I can't retrieve its number.
(In reply to :Gijs Kruitbosch from comment #13)
> This is because:
> 
> http://hg.mozilla.org/mozilla-central/annotate/643589c3ef94/browser/
> components/preferences/in-content/applications.js#l1719
> 
> assumes that the dialog open code is sync an will only return after an app
> has been picked (which is what it does on Windows non-in-content prefs).
> This is no longer the case in the in-content prefs. The windows code there
> probably needs to be in the unload handler for the subdialog or something
> like that.

We have the 4th argument to gSubDialog.open which is aClosingCallback to provide a callback. It should just be a matter of wrapping those few lines in a callback. We had to handle this situation a few times already but I guess I missed this one while reviewing.

> Points: --- → 5

With the solution above, I would argue this is easy.
Example which checks the button that was closed so we don't save on a Cancel (not sure if that applies in this case):

https://mxr.mozilla.org/mozilla-central/source/browser/components/preferences/in-content/main.js?rev=2234aaa1655a&mark=333,336-345#331
(In reply to Matthew N. [:MattN] from comment #15)
> > Points: --- → 5
> 
> With the solution above, I would argue this is easy.

I take that back if you were planning on writing a test though.
(In reply to Matthew N. [:MattN] from comment #17)
> (In reply to Matthew N. [:MattN] from comment #15)
> > > Points: --- → 5
> > 
> > With the solution above, I would argue this is easy.
> 
> I take that back if you were planning on writing a test though.

This was indeed my reasoning as well... Easy, but should have a test, and... Oh. :-(
Yeah, the fix(es - the manage apps bit was also busted) was/were pretty trivial. The tests, on the other hand, cost me most of today and a good amount of time yesterday...
Attachment #8553833 - Flags: review?(jaws)
Ugh, silly mistake on non-Windows (leaving try because I'm pretty sure it won't be able to tell anyway, AFAICT this is the first test for this code... let's see if I'm right)
Attachment #8553835 - Flags: review?(jaws)
Attachment #8553833 - Attachment is obsolete: true
Attachment #8553833 - Flags: review?(jaws)
Iteration: 38.1 - 26 Jan → 38.2 - 9 Feb
Comment on attachment 8553835 [details] [diff] [review]
setting app in about:preferences should also work on Windows,

Review of attachment 8553835 [details] [diff] [review]:
-----------------------------------------------------------------

Wow, I feel bad that I didn't catch that in my previous review. r=me
Attachment #8553835 - Flags: review?(jaws) → review+
remote:   https://hg.mozilla.org/integration/fx-team/rev/cd65efe1b24c
Whiteboard: [fixed-in-fx-team]
Flags: in-testsuite? → in-testsuite+
Flags: needinfo?(gijskruitbosch+bugs)
Priority: -- → P1
I could repro this locally with e10s; it seems like opening popups is finnicky.

Considering that just clicking items in the popup while it isn't shown at all works, I went with just nixing all the popup malarkey:

https://hg.mozilla.org/integration/fx-team/rev/94368a8d00f1

which seems to work fine here both inside and outside of e10s.
Flags: needinfo?(gijskruitbosch+bugs)
https://hg.mozilla.org/mozilla-central/rev/94368a8d00f1
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 38
QA Contact: camelia.badau
Verified fixed on Windows 7 using latest Nightly 38.0a1(buildID: 20150204030234).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.