Closed Bug 281806 Opened 20 years ago Closed 20 years ago

firefox does not associate .htm and .html to firefox when http protocol is already associated (when using set as default browser)

Categories

(Firefox :: Shell Integration, defect)

x86
All
defect
Not set
minor

Tracking

()

VERIFIED WONTFIX

People

(Reporter: chadwickgab+mozilla, Assigned: Gavin)

Details

Attachments

(1 obsolete file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.5) Gecko/20041108 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.5) Gecko/20041108 Firefox/1.0 When .htm files are associated with an other browser and .html with firefox, firefox does not detect it. Even if go in the settings and verify it manually it still does not detect it. So .htm files do not open with firefox. Reproducible: Always Steps to Reproduce: 1.Set .htm to open with internet explorer. Actual Results: firefox does not detect it and does set himself to open .htm so .htm are openned by ie. Expected Results: Detect it and set itself as default. It should open .htm files.
I'm confirming this. I edited my registry so that .htm is associated with "htmlfile" and .html with "FirefoxHTML", and FF does not complain that it is not the default browser even when using a manual check through the UI. Reversing this (i.e., .htm -> FirefoxHTML and .html -> htmlfile) does cause FF to complain. OTOH, MSIE detects it is not the default browser if either .htm or .html is not associated with it. Firefox's definition of "default browser" should at the minimum check for three things: .html, .htm and the http protocol.
Status: UNCONFIRMED → NEW
Ever confirmed: true
There is a simple workaround -> minor. This does appear to be by design, since we don't necessarily need/want to steal the html association. In fact, you can just have the web protocols and nothing local and we won't bat an eyelash. Whether we change this is probably an argument in waiting.
Severity: major → minor
(In reply to comment #2) By design ? There is some pieces of software out in the wild that only change one of the two to internet explorer. So imagine unexperienced users what surprise and missunderstanding they will face. Even more, when you check firefox to be default browser you expect it to handle every web page, maybe not everyone but unexperienced user do ! Ad to this, that it does not make using firefox easy and simple. > There is a simple workaround -> minor. > > This does appear to be by design, since we don't necessarily need/want to steal > the html association. In fact, you can just have the web protocols and nothing > local and we won't bat an eyelash. > > Whether we change this is probably an argument in waiting.
The bug still exist in 1.0.1 (In reply to comment #0) > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.5) Gecko/20041108 Firefox/1.0 > Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.5) Gecko/20041108 Firefox/1.0 > > When .htm files are associated with an other browser and .html with firefox, > firefox does not detect it. Even if go in the settings and verify it manually it > still does not detect it. So .htm files do not open with firefox. > > Reproducible: Always > > Steps to Reproduce: > 1.Set .htm to open with internet explorer. > > Actual Results: > firefox does not detect it and does set himself to open .htm so .htm are openned > by ie. > > Expected Results: > Detect it and set itself as default. It should open .htm files.
Assignee: bugs → gavin.sharp
Version: unspecified → Trunk
Status: NEW → ASSIGNED
I think that the file associations for .html and .htm should be included in the set of elements that are checked to determine whether or not Firefox is the default browser. I also think that it should be a required element for the browser to function.
Attached patch Patch (obsolete) — Splinter Review
Require .htm, .html to be registered to Firefox for the browser to consider itself the default.
What if someone wants their editor to own local files, and their browser to own HTTP? That's a pretty common case, and not something I feel we want to break. Reasons instead of opinions are what can convince people. If the old default browser didn't own .htm why should we take it? Same with if an editor steals the association afterwards. If that's what the user wants, why should Firefox make that difficult/annoying?
Mike, a program stealing it when installed for something else, (lets use M$ word as an example, I cannot recall if it associates html with itself or not, but it does handle them), I know of few people who want html files to open in Word, and by most installations of Word, it is for a "Word Processor". I am sure some other programs may claim html when html/htm are not the primary use-cases of the program. However to play my own devil's advocate, I do see your point, we could provide an "Advanced" UI (perhaps) to say "Reclaim htm/html files when Firefox checks if it is the default browser" or some such syntax (will require more code, but makes sense to me, to suit both cases of "Firefox should not annoy users".)
Adding a pref because you can't satisfy everyone is an incredibly huge cop-out. We don't do that here 95% of the time.
Attachment #177947 - Attachment is obsolete: true
In any exeption case all you have to do is to stop firefox checking if it is default. But i think that the default setting should be to look for htm and html. You cant have a browser, as a default, look for only one of them it does not make sense. Most of the users I think will exepect that. (In reply to comment #7) > What if someone wants their editor to own local files, and their browser to own > HTTP? That's a pretty common case, and not something I feel we want to break. > > Reasons instead of opinions are what can convince people. If the old default > browser didn't own .htm why should we take it? Same with if an editor steals > the association afterwards. If that's what the user wants, why should Firefox > make that difficult/annoying?
Actually, currently neither is required. One or the other may or may not be set, and we won't bat an eye. Having to turn off a check just because you have a valid but not standard config isn't the best idea. Note that this issue only occurs if an app takes the association afterwards. I don't think its good practice to rabidly try to take back file associations over what is usually the user's wishes.
I have something to ad. I am thinking about normal users that want all web pages to be open by there default browser. People who dont know how to mess with files associations how can the get it back if firefox cant... Unchecking an option is not a big problem and it will touch a minority. Messing in the files association preferences is though for many users. Firefox should take back by default htm and html.
Summary: firefox does not associate .htm to firefox when .html are already associated → firefox does not associate .htm and .html to firefox when http protocol is already associated
OS: Windows XP → All
I believe this bug is what I am experiencing, if not I apologize. on a Windows XP box, using Novell's GroupWise, when you click on a html link in an email, it is supposed to open up in the default browser, which I have set to be FF. However what happens is that IE opens up. And in researching this I found an article from Novell (http://www.novell.com/coolsolutions/tip/11537.html) that shows that FF is not setting all of the registry keys associated w/ being the default browser. Here is what they said: The following are the keys that weren't being set by Firefox, and that were being used by GroupWise to call a browser when an email link is clicked. [HKEY_CLASSES_ROOT\htmlfile\DefaultIcon] @="C:\\PROGRA~1\\MOZILL~1\\FIREFOX.EXE,1" [HKEY_CLASSES_ROOT\htmlfile\shell\open\command] @="C:\\PROGRA~1\\MOZILL~1\\FIREFOX.EXE -url \"%1\"" [HKEY_CLASSES_ROOT\htmlfile\shell\open\ddeexec\Application] @="firefox" [HKEY_CLASSES_ROOT\htmlfile\shell\opennew\command] @="C:\\PROGRA~1\\MOZILL~1\\FIREFOX.EXE -url \"%1\"" [HKEY_CLASSES_ROOT\htmlfile\shell\opennew\ddeexec\Application] @="firefox" Havng to manually edit the registry to have FF really become the default browser seems like a bug to me, and so I would like to add my support to this being resolved in the next release of FF.
Asking for blocking because i think(or hope) this is simple to fix and important enough to be included in 1.1 . This can be a way to lose unexperienced users.
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1? → blocking-aviary1.1+
Target Milestone: --- → Firefox1.1
I tested this with IE. They don't enforce even as much as we do. I actually changed the http/https associations, in addition to htm/html, and it still didn't prompt. That being said, I'm glad we enforce what we enforce, and no further. Under XP (our target Windows platform, and the base OS for pretty much every consumer PC sold in the last three years or more), users can easily fix the association. Right-click, Open With, Choose Program, check "Always use this program". This is the same as any other file type that gets the wrong association, and other apps (i.e. Office, Winamp, etc) don't nag if not all file types they can handle aren't associated, even if some are. Aside: reporter, the target milestone is not something you set for others. Please don't touch fields just because you can, find out who should be setting them. Marking this WONTFIX, the annoyance to users who actually want this setup outweighs the possible confusion of a user who's had his file associations stolen. The flipside is that a user who doesn't get file associations, but wants local HTML files to open in whatever editor, they won't understand WHY Firefox keeps brekaing their editor.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Flags: blocking-aviary1.1+
Resolution: --- → WONTFIX
Target Milestone: Firefox1.1 → ---
Status: RESOLVED → VERIFIED
Summary: firefox does not associate .htm and .html to firefox when http protocol is already associated → firefox does not associate .htm and .html to firefox when http protocol is already associated (when using set as default browser)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: