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

Status: VERIFIED FIXED

(Firefox :: Settings UI, defect, P1)

Description

[User Dderss]

Attachment: Nightly 37 [e10s] does not allow to manually set an application as action, keels 'Always ask'.png

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).

Comment 1

[Loic]

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"?

Comment 2

[User Dderss]

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".

Comment 3

[Dragana Damjanovic [:dragana]]

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.

Comment 4

[:Gijs (he/him)]

(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 localstore.rdf file to localstore-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?

Comment 5

[:Gijs (he/him)]

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?

Comment 6

[User Dderss]

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?

Comment 7

[:Gijs (he/him)]

(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? :-)

Comment 8

[User Dderss]

Attachment: 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).

Comment 9

[:Gijs (he/him)]

Odd, it's valid XML. I'll try to have a look next week. :-\

Comment 10

[User Dderss]

You can search for "torrent" and see the difference between "application/torrent" and "application/x-torrent".

Comment 11

[:Gijs (he/him)]

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.

Comment 12

[:Gijs (he/him)]

This works in the windowed preferences, but not in in-content prefs.

Comment 13

[:Gijs (he/him)]

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.

Comment 14

[Loic]

I'm sure there is a dupe of this bug where I replied previously... but I can't retrieve its number.

Comment 15

[Matthew N. [:MattN]]

(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.

Comment 16

[Matthew N. [:MattN]]

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

Comment 17

[Matthew N. [:MattN]]

(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.

Comment 18

[:Gijs (he/him)]

(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. :-(

Comment 19

[:Gijs (he/him)]

Attachment: setting app in about:preferences should also work on Windows,

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...

Comment 20

[:Gijs (he/him)]

Attachment: setting app in about:preferences should also work on Windows,

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)

Comment 21

[:Gijs (he/him)]

remote:   https://treeherder.mozilla.org/#/jobs?repo=try&revision=efd2a8c8e816

Comment 22

[Jared Wein [:jaws] (please needinfo? me)]

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

Comment 23

[:Gijs (he/him)]

remote:   https://hg.mozilla.org/integration/fx-team/rev/cd65efe1b24c

Comment 24

[Ryan VanderMeulen [:RyanVM]]

Backed out for frequent Win8 M-e10s test failures.
https://hg.mozilla.org/integration/fx-team/rev/a98a30ba9ce0

https://treeherder.mozilla.org/ui/logviewer.html#?job_id=1818707&repo=fx-team

Comment 25

[:Gijs (he/him)]

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.

Comment 26

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/94368a8d00f1

Comment 27

[Camelia Badau [:cbadau], Desktop QA]

Verified fixed on Windows 7 using latest Nightly 38.0a1(buildID: 20150204030234).