Closed
Bug 131106
Opened 22 years ago
Closed 19 years ago
Make 'default browser' shouldn't steal image file associations from image programs
Categories
(SeaMonkey :: UI Design, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: cyp, Assigned: mcsmurf)
References
()
Details
(Keywords: helpwanted)
Attachments
(1 file, 1 obsolete file)
1.38 KB,
patch
|
neil
:
review+
jag+mozilla
:
superreview+
asa
:
approval1.8b3+
|
Details | Diff | Splinter Review |
During automatic reassignment of filetype handers, Moz 0.9.9 reassigns the filetype handlers for various image formats to itself. This is well and good IFF those filetypes were not previously assigned or they were assigned to another browser. However, such behaviour is simply NOT acceptable if those filetypes were assigned to any other class of application - for example, one capable of editing them, or even one that simply displays them but does so faster than it would take Moz to start up. This is particularly so for .BMP and .ICO files - How incredibly arrogant for Moz to assume that it can handle Windows-*NATIVE* file types better than Windows itself can. I just did a "mass" install of 0.9.9 on ten WinNT 4 workstations, one of which had Graphics/Photo editing software installed on it. The image filetype assignments on that machine are now shot. Suggestion: When reassigning file types, compare the filename of the existing image file type handler against a) the filename assigned for the .htm[l] filetype b) "IExplore", "Netscape", "Mozilla" "Opera" et al If either matches go ahead and reassign, otherwise leave the dang thing alone.
Comment 1•22 years ago
|
||
AFAIK the installer asks you if mozilla should handle supported filetypes. You can revert this (AFAIk) if you go to Edit\preferences\Advanced\system und uncheck some filetypes. BTW: Do you used the installer or zip builds ? -> Xp APPS
Assignee: asa → trudelle
Component: Browser-General → XP Apps
QA Contact: doronr → paw
Comment 2•22 years ago
|
||
Thanks for the lecture, Cyrus. You might want to consider testing pre-alpha software before installing it on multiple production machines. Could you please provide exact steps to reproduce this defect, including exactly how you installed?
Reporter | ||
Comment 3•22 years ago
|
||
In the scenario described above I only did 10 workstations, and there was only one that needed to be reverted. But what if there were (say) 100 workstations? Its a support nightmare in the making. Anyway, thats not the point. The point is that Moz should be smart enough (and as I think I explained, it doesn't take a lot of smarts) to figure out which file types it is indeed capable of handling better than the existing handler. To head of an argument about whether Moz is better suited to do X or not - Moz's _primary_ file type is .html, and if I didn't think Moz was better suited to handle .html, I wouldn't be installing it. But there are dozens, if not hundreds, of tools that are far better suited for dealing with images, and in such a case Moz should be circumspect in overriding the association.
Reporter | ||
Comment 4•22 years ago
|
||
Sorry, didn't mean to sound condescending. Install details follow...
Reporter | ||
Comment 5•22 years ago
|
||
Attached to my office I have a bunch of machines that I can use to install software before I let it out into the wild. These machines are not really production grade, but they are used by normal joe users. In this scenario, what I did was: a) Install a central (file server) copy of 0.9.9 - Browser only, using the .zip b) Build a default profile that is also stored in a central location. The profile is read-only. There are no user-specific settings in the prefs other than the location of their bookmarks, which is the same path (file mapping) for each users (each user has his own 'M:\'). History is non-persistant of course, and Mail settings are not required since this is browser only. Cache is on the local machine and is cleared when the next user logs in. c) The workstations do not have individual user accounts. The login is to a NetWare file server - on the workstation the user is not much more than guest. The "Application Data\Mozilla\registry.dat" is a login-time copy of one from the Default User settings.
Comment 6•22 years ago
|
||
Could you please try installing one clean new copy on one local machine, and seeing if you can reproduce this? Also, do you get any dialogs asking if you want the browser to become the default?
Reporter | ||
Comment 7•22 years ago
|
||
If Moz is installed by simply copying files over (from a .zip or from another drive, or even if the path changes), then the first time Moz is run, it will prompt with a simple yes/no dialog asking if user wants the browser to become the default. If Moz is installed from the installer, then no such dialog appears when Moz starts up for the first time. Reassignment has presumably been already done by the installer. When reassignment is done (either because the user says "yes", or automatically by the installer), not only is html (and company) reassigned, all image types supported by Moz are reassigned too, irrespective of what they may have been previously assigned to. To be clear: its the "irrespective of what they may have been previously assigned to" clause that I have a problem with. If the image types are not previously assigned, or are assigned to IE (or other browser), well, hey, I expect Moz to take them over. But if the image types are assigned to some tool other than a browser, then it doesn't make sense for Moz to handle them because that other tool is almost certainly going to be "better" (smaller/faster - or has image handling as its specialty) than Moz at the task. I hope you'll see that loading an executable with 20MB+ mem footprint to load an itty-bitty icon (or whatever) is a bit of an overkill.
Comment 8•22 years ago
|
||
*** Bug 131110 has been marked as a duplicate of this bug. ***
Comment 9•22 years ago
|
||
marking NEw based on the dupe. FYI: NS4.7x displays a dialog after the installation where you can select/unselect all filetypes.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 10•22 years ago
|
||
These associations can easily be undone via the prefs dialogs (we save the previous values), but that doesn't help Cyrus a whole lot if he's rolling out to multiple machines. Should which types get associated be a CCK option, so site admins can customize their roll-outs?
Comment 11•22 years ago
|
||
That sounds good for enterprise customers, but I think most users would best be served by what Cyrus is asking for. I doubt this would make mozilla1.0 or even MachV though. ->law. Bill, was this the intended bahavior?
Assignee: trudelle → law
Comment 12•22 years ago
|
||
It was the intended behavior, I believe, although that may not have been an entirely good idea. This was patterned after the way Communicator 4.x worked, I believe. As we added support for additional image types (especially .bmp and .ico), they got added to the set we take over automatically when the user says they want us to be the "default browser." .bmp and .ico are fixed as part of pending bug 92527, BTW. The problem is the inherent conflict between wanting to simplify things for some users while not stepping on the toes of others. If we don't set ourselves up as the default handler for various graphic file types, then users might have some trouble figuring out how to do that later. It seems like the logic should be something like: var oldBrowser = current_html_handler; for ( var ext in list_of_image_types ) { if ( handler_for( ext ) == oldBrowser ) { makeMozillaHandle( ext ); } } I'm not sure how well that would play out in the real world, but it seems relatively safe. The only downside is that we might not end up commandeering as many file types as we would otherwise. Most users wouldn't care, since presumably the current handler is doing the job for them OK.
Reporter | ||
Comment 14•22 years ago
|
||
The logic Bill describes sounds good to me. One might also want to check against 'no handler assigned' to calm concerns that Moz is not reassigning enough. var oldBrowser = current_html_handler; for ( var ext in list_of_image_types ) { currHandler = handler_for( ext ); if ( currHandler == NULL || // extension is not registered at all currHandler == "" || // extension does not have a handler currHandler == oldBrowser ) { makeMozillaHandle( ext ); } }
Reporter | ||
Comment 15•22 years ago
|
||
There is one condition that is not covered by the above pseudo-code: Say... a) the user installs Browser A that _does_ supports extention .abc, b) user later installs Browser B (or reverts to using his/her other older browser), which doesn't support extension .abc c) user installs Moz - Moz will look at the association for .abc, find it doesn't match Browser B, and not update the association. To ensure that such an exclusion doesn't occur (and it could happen even today, with .png and older browsers for example), the logic could be extended to read: var oldBrowser = current_html_handler.toLowerCase(); for ( var ext in list_of_image_types ) { var currHandler = handler_for( ext ).toLowerCase(); if ( currHandler.Length() == 0 || currHandler == oldBrowser || currHandler.indexOf('mozilla') != -1 || currHandler.indexOf('iexplore') != -1 || currHandler.indexOf('netscape') != -1 || currHandler.indexOf('navstart') != -1 currHandler.indexOf('opera') != -1 ) { makeMozillaHandle( ext ); } } This won't cover _all_ eventualities (it breaks down for example if the user happens to rename the binary), but it does cover _virtually_ all of them. :)
Comment 16•22 years ago
|
||
i'm strictly opposed to us hard coding a list of browsers for this code. If all editing apps were nice and wrote their key as 'edit' instead of 'open' and specified edit as default, then we'd have some reasonable logic to use here, but they don't.
Comment 17•22 years ago
|
||
*** Bug 133909 has been marked as a duplicate of this bug. ***
Comment 18•22 years ago
|
||
*** Bug 135564 has been marked as a duplicate of this bug. ***
Comment 19•22 years ago
|
||
Zip builds: Mozilla should ask on first run for the default browser thing as it does now. If the user answers positively: 1. Associate the "main, crucial" file types and handlers that Mozilla can handle (http://, .*htm* and whatever like that). 2. Associate the types that Mozilla can handle, that are claimed by an executable with the same name as this currently running executable. 3. Associate the types that Mozilla can handle, that are not claimed by any application. Mozilla must not claim any file types that are already claimed by other apps, besides the "main" ones, as there is no uninstall; If user removes Mozilla, the associations would have to be repaired by hand or by reinstalling some other software. Point 2 above is the case where the file type is claimed by a previous installation of Mozilla (or other Mozilla-based app). Installer: Installer should present a list of association checkboxes as n4 does. Initially, the following checkboxes should be selected: 1. The "main, crucial" types (see zip.1) 2. Associated with another Mozilla (see zip.2) 3. Unclaimed (see zip.3) 4. File types associated with the previous browser app (see comment 12) In the installer case, Mozilla can, by default, select types beyond the "main" types because they can be easily changed here. Web browsing capability in software X does not really imply lesser suitability than that of moz for image viewing, so I don't agree with the web-browser hardcoding solution of comment 15. Points {1,3,4} mean approximately the same as the algorithm in comment 14. Concerns in comment 12: I think this sufficiently addresses "wanting to simplify things for some users" as the good defaults supplied in the Installer case allow the user to blindly hit "Next>" without actually thinking. In the Installer case simplifying thins is not really an issue, as real people don't use those. The "users might have some trouble figuring out how to [set moz as the default handler of graphic types] later" is really not applicable in the Zip build case, as real people don't use those, and the steps I outlined above will correctly migrate the Mozilla-related associations from an older moz build for a fanatic tester switching zip builds. I think this also sufficiently addresses "not stepping on the toes of others" (comment 12), as no seemingly unrelated hidden changes that affect other apps are carried out in the zip build case by just pressing "Yes"; in the Installer case, the associations, while likely clobbering those of other apps, can be overridden "as it happens" without hunting through the prefs afterwards.
Comment 20•22 years ago
|
||
er, "In the Installer case simplifying thins is not really an issue, as real people don't use those." -> s/Installer/zip build/ :)
Comment 21•22 years ago
|
||
*** Bug 143621 has been marked as a duplicate of this bug. ***
Comment 22•22 years ago
|
||
*** Bug 144417 has been marked as a duplicate of this bug. ***
Comment 23•22 years ago
|
||
One installation screen (maybe only in the custom install) giving options like: [x] associate html files with Mozilla [x] associate image files with Mozilla is really all that's needed (perhaps one might other post-install options to the same screen, such as placing an icon on the desktop or in the start menu). I doubt the current behaviour is making it easier for the novice user, since they won't know how to fix the original file associations. The lack of the options is more likely to annoy the more advanced user. The "intelligent" method discussed in this thread is nice, but should be customisable. The novice user will simply click "next" anyway.
Comment 24•22 years ago
|
||
I just installed a new version of RealPlayer One Gold. This is the best installation I have seen. For the files to associate it always tells you (only custom I guess) which application has it right now (if it is not RealPlayer) and asks you if you want to override it. Great stuff! pi
Comment 25•22 years ago
|
||
*** Bug 149464 has been marked as a duplicate of this bug. ***
Comment 26•22 years ago
|
||
Re: comment 1 to dupe bug #149464 ------- Additional Comment #1 From Matthias Versen (Matti) 2002-06-05 18:24 ------- >Mozilla asks you if Mozilla should handle file types. >(no list, it reassigns all supported file types if you select "yes") I have installed RC1, RC2, RC3, and finally version 1.0. I also installed several other builds in the meantime. NEVER ONCE was I asked before Mozilla buggered up my file associations. In the last hour I have installed version 1.0 two dozen times just to watch for some obscure warning about this and I haven't seen it yet. I even got someone else to install it a few times while I watched and he didn't see anything either. Mozilla asks you if you want it to be your default browser. IT NEVER EVER asks you if you want it to be your default image viewer. When you say "Yes" to it being your default browser, why on earth would you think you are also giving it permission to take over completely unrelated file associations ? >This is NEVER critical and it's a dupe. It _is_ absolutley critical because whereas I know half a dozen ways to repair file associations on a windows machine, most users don't know a single one and they panic when their computer is suddenly "broken". Some of these people have yet to realize it is Mozilla's fault - they think they have a virus and they are going bats because they can't get a human being on the phone at Symantec or McAfee. I have already fielded two dozen phone calls so far today from people who needed my help in fixing this major Mozilla f*ck up. I've had to take my phone off the hook because of those stupid morons who created that f*cked up Mozilla installer ! And that two dozen calls is just the ones who have tried to use their image editors/viewers since they installed Mozilla. I shudder to think of what tomorrow will be like. I'd been warning everyone who said they were waiting for Mozilla 1.0's impending release that it was nowhere near being ready for the general public and today has proven me right. And I don't have time to help everyone - all I can do is suggest they uninstall it and wait for version 2.0.
Comment 27•22 years ago
|
||
Erm, do you mind? There is no need for such language. While I agree that this is an important issue, it is hardly the end of the world. The Mozilla contributors have put a lot of effort and plain old hard work into the program. Give them a break!
Comment 28•22 years ago
|
||
>I have installed RC1, RC2, RC3, and finally version 1.0. >I also installed several other builds in the meantime. >NEVER ONCE was I asked before Mozilla buggered up my file >associations. This is worksforme with all builds on win2k. BTW: You can uncheck the image associations via edit\preferences\advanced\system >It _is_ absolutley critical because whereas I know half a dozen It's possible critical for you but not for mozilla.org and you are only a tester because mozila.org has only test builds. Mozilla is not for End-Users. Critical= Dataloss, crash, severe memory leak
Comment 29•22 years ago
|
||
mozilla does this sometimes. I'm not able to reproduce this 100%, but sometimes JPG's are taken over by Mozilla...:(
Comment 30•22 years ago
|
||
The suggestion in comment 14 sounds like a good solution for this. It will make sure that all users who have a specific image editor will not loose those file type associations, while users with no current file associations will be using Mozilla by default. This solution is enough, and probably not very hard to implement. I'm voting for this.
Comment 31•22 years ago
|
||
Matti (comment 28) , this is _not_ a worksforme. I have had to reinstall my win2k the other day. I installed RC3, and upgraded to 1.0 today - I was also never asked anything about file types. But it overwrites all installed handlers. If you unckeck the file types under Edit->Prefs->Advanced->System just ONCE, then subsequent installations wont blat file handlers, which was why this bug didnt bother me after I changed it once it back in 0.9.4. But for users installing 1.0 for the first time, this is going to put them off in a huge way. Newbies won't know how to reassign their file handlers to acdsee, photoshop or whatever. Until this can be fixed, default behaviour should at least be set such that it doesnt change any associations. IE is image handler by default on a new windows setup, so moz isnt exactly adding new functionality by assigning itself to jpegs/pngs etc
Comment 32•22 years ago
|
||
Re: Comment #30 I would strongly disagree with implementing the algorithm in comment #14. Mozilla is completely unsuitable for use as a general image viewer and has no image editting capabilities, and hence should default to only concerning itself with images that are needed in order to render web pages. If a user wants to associate Mozilla with images, then let him do so, but this association should not be a default even if there exists no previous file association for those image types. The installer shouldn't even insult the user's intelligence by asking if he wants to associate images with Mozilla - it should assume that he doesn't.
Comment 33•22 years ago
|
||
*** Bug 150357 has been marked as a duplicate of this bug. ***
Comment 34•22 years ago
|
||
*** Bug 153919 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 35•22 years ago
|
||
new bug related to reassignment of filetype handlers (should perhaps be a new bug with dep on this one, but I'll leave that to someone else to decide) Mozilla is blindly backing-up the old file type handlers (does not check if the old file type handler was mozilla too). A Mozilla upgrade will clobber the "old" (saved) file type handlers from the previous installation (the ones that would have used in an 'undo') with the "current" settings of the previous installation. The 'undo' settings are then lost forever. Example: before installing any version of mozilla: .gif=kodakimg.exe after first install of mozilla: .gif=mozilla.exe undo=kodakimg.exe after another install of mozilla: .gif=path-to-new-moz/mozilla.exe undo=path-to-old-moz/mozilla.exe If a user were to uncheck the .gif filetype (in Edit->Preferences->Advanced-> System) after the second install, the .gif filetype would be pointing to the old mozilla version rather than the expected kodakimg.exe This is true even if the new mozilla was installed into the same directory as the old installation (file handler paths are unchanged).
Comment 36•22 years ago
|
||
It is not nice behaviour. I use IE as main browser until I am happy that mozilla/netscape works as I need it to. I need to have Netscape4/6/7 AND Mozilla keep their hands off ALL!! associations since I do NOT need them to handle anything but urls I type in or drop on them or open via file/open Also some associations are set up to use DDE and it is not simple to get that back - that ruins my link from my html editors Thanks
Comment 37•22 years ago
|
||
*** Bug 156740 has been marked as a duplicate of this bug. ***
Comment 38•21 years ago
|
||
Someone please please please have Moz NOT touch existing file-type handlers. I've been switching between 1.0.1 and 1.1 builds and everytime I have to reset the .jpg and .gif handlers (despite removing the settings under preferences->advanced->system after each install) PLEASE someone fix this, its must **** people off endlessly. This is so invasive for users, especially new users who don't know how to reassign file handlers. I can't think of a good reason why the heck anyone would want to assign moz to handle gifs and jpegs ?! just turn it off ! its pointless and annoying !
Comment 39•21 years ago
|
||
I use different Mozilla builds and i have no problems with the file type handler.
I get a dialog on every installation and Mozilla has never reassigned the
file-types without aksing.
>just turn it off ! its pointless and annoying !
why ?
This works for many users including me.
Comment 40•21 years ago
|
||
> I use different Mozilla builds and i have no problems with the file type > handler. Under Win32 (NT->2000->XP anyway) I've *always* (for years now) had this problem with clean Mozilla installs. (If I do an install on top of an existing install it will not reassign the file type handler - but if I've removed the previous install and put a new one on, it always does.) > I get a dialog on every installation and Mozilla has never reassigned the > file-types without aksing. This is very strange. I've *NEVER* seen a dialogue asking me about file-types. I always have to go into Preferences->Advanced->System after the fact and "fix" what the installer's done without my permission.
Comment 41•21 years ago
|
||
>> I get a dialog on every installation and Mozilla has never reassigned the >> file-types without aksing. > This is very strange. I've *NEVER* seen a dialogue asking me about file-types. So is my experience. I've never been asked about that issue. But for some time (and reason) Mozilla seems not to grab all file types any more here... (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020824)
Comment 42•21 years ago
|
||
Matti: I've never seen a file-handler dialog box in about 50 installs of Moz on 5 different machines. It's annoying because a new windows install has IE already assigned as image viewer. IE starts quicker than Moz. If a user really really wants to have moz open images, then they can do it manually via preferences. Simply because Moz has the ability to view jpegs and gifs (and pngs for that matter) doesnt make it the most efficient choice.
Comment 43•21 years ago
|
||
chg summary re. duplicates
Summary: Bad behaviour of automatic reassignment of filetype handler → Bad behaviour of automatic reassignment of filetype handler (make 'default browser' steals image file association)
Comment 44•21 years ago
|
||
*** Bug 149682 has been marked as a duplicate of this bug. ***
Comment 45•21 years ago
|
||
*** Bug 164948 has been marked as a duplicate of this bug. ***
![]() |
||
Comment 46•21 years ago
|
||
There is another problem... In addition to the image types we set ourselves as the default HTML _EDITOR_. I fail to see how any stretching of the definitio of "Browser" or argument for convenience can possibly justify asking someone "Should I be your browser?" and then wiping out the editor association. Nominating; this is one of the more serious perception/usability issues we have at this point, imo.
Keywords: nsbeta1
Comment 48•21 years ago
|
||
I just wanted to point out that on Windows OS machines, "default browser" is a totally different thing than "file associations." The "default browser" setting doesn't at all depend on any file association. I've had my HTML files (all flavors, .htm, .html, .asp, etc.) assigned to a text editor for years now, and yet I've simultaneously had my "default browser" set to first IE and now Mozilla, and most of the time, Win98 properly finds my default browser instead of my text editor when it needs to (occasionally it goofs up, but what do you expect, it's Windows). My point is this: In no case is asking "Should I be your default browser" sufficient to cover "Should I grab all of your file associations" because the two aren't even the same thing. This may be what's throwing a lot of people off, causing them to not even realize that Mozilla is, indirectly, actually asking first before it steals all the file associations.
Comment 49•21 years ago
|
||
The original bug I filed was about Mozilla 1.0 taking the default browser position, although I didn't tell it to. This bug seems to have been closed and merged in this one since I still get the emails about it. I have verified that Mozilla 1.2 doesn't do this anymore. Also, I found that Mozilla 1.0 didn't do this on other setups I applied it to. It only did it once. As for the current 1.2 installation, I did a "custom" one and I think it didn't even ask me about "default browser". When I launched it the first time it asked me (actually, it was automatically launched right after installation), I said "no" and it respected this. I haven't seen any change yet. As for the difference between "default browser" and file associations mentioned recently. If you set a browser to be the default it will also grab the .htm(l) file extensions, otherwise it doesn't make any sense being the default. If the browser is the "default" but not the default "Open" command for html files then it won't launch if one opens an html file. It will still open for links, Favorites etc., but it won't open html files, making it in fact more like a "half-default" browser. As for the image file association. This is initially set by default to IE and/or the Windows Image Viewer on Windows. If you later change default browser and then back to IE I'm quite sure that IE does NOT touch it (in case another image viewer is now the default). This is only the case with a "fresh" Windows installation and I think the reason is for the "Preview in folder" function in Explorer (Windows Explorer). I'm not sure if Preview stops working when un-associating IE, I never use it. However, what I know is that the Mozilla 1.0 install which grabbed the default browser position without asking me did NOT grab the image file associations. Generally, I also don't see a reason why Mozilla should associate itself with this kind of files if made the default browser.
Comment 50•21 years ago
|
||
*** Bug 186446 has been marked as a duplicate of this bug. ***
Comment 51•21 years ago
|
||
See also my bug 186450 about a related issue. In my view if there are right-click options that Mozill is not going to replace (could be "Open with Foo" cusotm option) these should be copied in to the new file association. Please mark 186450 as duplicate if you feel that that issue belongs here
Comment 52•21 years ago
|
||
My comment 51 should refer to Bug 186449 not to Bug 186450 which has been marked as Duplicate. Apologies - my bug got listed twice due to a net glitch
Updated•21 years ago
|
QA Contact: tpreston → pmac
Comment 53•21 years ago
|
||
*** Bug 193600 has been marked as a duplicate of this bug. ***
Comment 54•21 years ago
|
||
Suggestion: Change "do you want mozilla to be the default web browser" dialog: include an 'advanced' button, which opens another dialog (or extends the existing one) to ask what file associations and protocols you want to point at Mozilla).
Comment 56•21 years ago
|
||
Yes, this would be nice, but annoying if you install a second time. A workaround can be found in the URL above. Another solution would be bug 140886. pi
Comment 57•21 years ago
|
||
2 things i'd like to add: 1. the default browser dialog - it should only take to himself browser files (.*ml) 2. when installing mozilla - normally in installations, there is a "associate with ... files" dialog. it would be pretty intuitive. now, when i'm making a clean installation to dialog i say no, and then through preferences i add all .*ml files to be handled by mozilla. users, which install mozilla for first time, get frustrated after friendly answering "yes" to mozilla's proposal :) i propose this to be a 1.3 blocker
Flags: blocking1.3?
![]() |
||
Comment 58•21 years ago
|
||
If you think this is blocking 1.3, you need to find someone to do it, like I said in comment 55 (Bill Law no longer works on Mozilla).
Updated•21 years ago
|
Flags: blocking1.3? → blocking1.3-
Updated•21 years ago
|
Comment 59•21 years ago
|
||
My apologies about changing the nsbeta1- keyword - my mistake. Reverting now.
Comment 60•21 years ago
|
||
*** Bug 197390 has been marked as a duplicate of this bug. ***
Comment 61•21 years ago
|
||
*** Bug 197630 has been marked as a duplicate of this bug. ***
Comment 62•21 years ago
|
||
*** Bug 207370 has been marked as a duplicate of this bug. ***
Comment 63•21 years ago
|
||
*** Bug 209743 has been marked as a duplicate of this bug. ***
Comment 64•21 years ago
|
||
This has happened to me as long as I can remember with Mozilla. It happened when I installed any 1.3 version, and now with 1.4rc1 and rc2. After the installation, Mozilla becomes the associated program for every imaginable image file - png, jpg, gif, etc. I know how to change them back, but it is tedious. Why would the Mozilla install do this? It makes no sense to use Mozilla as an image viewer. And it can not edit the files either.
Comment 65•21 years ago
|
||
If there is a consensus on *what* the fix needs to be, I'll look at implementing it.
Comment 66•21 years ago
|
||
IMHO, Mozilla should just be associated with http/s protocols, and HTML filetype. Maybe another prompt if you hit 'yes' saying something like "If you wish to use Mozilla for opening image files, this can be set in Edit > Prefs > Advanced > System by ticking the appropriate boxes.". Another suggestion - should that 'System' section be called 'File Types' or 'File Type Handling' instead?
Comment 67•21 years ago
|
||
William, I described a work around in the URL above. Aaron, the best fix IMHO would be fixing bug 140886. The other option would be to have check boxes when asking to assign. pi
Comment 68•21 years ago
|
||
It seems to me that bug 140886 is a separate, but related issue because it doesn't seem to address what to do when installing for the *first* time. I think an Advanced button and dialog would be good (this is what Quicktime and other programs do).
Comment 69•21 years ago
|
||
I think it could be as simple as asking something like: Should Mozilla be the default WEB BROWSER? [ Make Default Browser ] [ Keep Current Settings ] Should Mozilla be the default IMAGE VIEWER? [ Associate with Images ] [ Keep Current Settings ] Also I think it would be better to ask these questions during the installer run instead of during the first browser run. This is easily one of the first and most frequent complaints I hear from people whom I get to use Mozilla. Browsing websites and opening image files from Explorer are two separate activities IMHO.
Comment 70•21 years ago
|
||
> Should Mozilla be the default IMAGE VIEWER?
I believe that this question should only be asked if there ARE no image viewers
currently assigned. I can't imagine a situation in which somebody would want to
have Mozilla be the image viewer (as opposed to any number of other better
suited applications), unless they don't currently have one associated with those
filetypes.
If an image viewer is already in use, then the question should not appear AND
Mozilla should not take it over. (Although the user is free to go into
Preferences and have Mozilla take over from the other if that's what they really
want.)
Mozilla viewing images is such an obscure thing that the question would likely
confuse people more than anything else. (Currently, there is no confusion just
annoyance. I'd like to see neither of those things.)
Comment 71•21 years ago
|
||
> > Should Mozilla be the default IMAGE VIEWER?
> I believe that this question should only be asked if there ARE no image viewers
currently assigned.
I think that will pretty much never be the case - I believe IE is the default
image viewer on Windows (maybe not ancient versions), so images will be
associated with that, unless they have been associated with something else.
I would imagine that was the original reason for Netscape 4.x grabbing images -
the concept is more "take over the stuff that IE does" than "default browser".
(Not that I think it's a good idea for Mozilla to do it just because IE and
NS4/6/7.0 do it - I'm just guessing the original reasoning)
Comment 72•21 years ago
|
||
Also, re comment #69 we'd need stuff like default FTP client, etc, and the backend is in no condition to handle that (bug 160896). The point is that we don't want lots of config options for the basic dialog (hence the advanced button). I think we shouldn't overwrite the image viewer, unless it's registered to IE. And since we don't want to hard code application names, I guess we shouldn't overwrite it ever. Now, what do we do about .XML? And FTP and Gopher for that matter? How about HTML _Editor_?
Reporter | ||
Comment 73•21 years ago
|
||
I'm still of the opinion that its best to follow the KISS ("Keep it simple stupid") principle. The preferences dialogs are complex enough as it is, and fulfill their purpose (with respect to this bug) well enough. They don't need changing. The issue at stake therefore is what actually to do when starting up mozilla for the _first_time_ and it finds that it not the default browser. The "make mozilla your default browser" message box that currently pops up is actually quite sufficient IF the logic behind a "Yes" selection is 'intelligent' (which it currently is not). Currently selecting 'Yes' blindly reassigns _all_ extensions to mozilla. What it _should_ do is reassign those extensions to mozilla that _faithfully_ answer the question "would you like to make mozilla your default browser". If you were to interpret that question as "would you like to make mozilla handle any extension/protocol that is currently registered registered to a non-mozilla browser?", the action to take becomes obvious: a) find out which application is servicing the "http" protocol. http_handler = get_appname_from("HKCR\http\shell\open\command\@"); b) for $proto in (http,https,ftp,gopher,appliction/http etc) { handler = get_appname_from($proto); if (user_said_yes && handler == http_handler) set_mozilla_as_default_handler($proto). else leave_existing_mimetype/protocol_handler. } c) for $ext in (.htm,.html,.jpg,.jpeg,.jfif,etc) { add_mozilla_to_OpenWith_list($ext) handler = get_appname_from($ext); if (user_said_yes && handler == http_handler) set_mozilla_as_default_to_OpenWith($ext). else leave_existing_extension_handler. } Note that, for extensions, mozilla always becomes a handler, but even then it is not necessarily the default for that extension. That way it becomes possible for a user to open a file with mozilla if he/she should want to (in the shell: rightclick -> "Open With..."), but the default handler (leftdoubleclick or rightclick-> "Open") remains unmodified _unless_ he/she said 'yes' to the message box _and_ that extension was previously assigned to another browser.
Comment 74•21 years ago
|
||
Comment 68: Right, this works not for the first install. But it saves all the work later. The best solution I have seen so far was for Realplayer. It listed everything it could take and saying who has it now. So you could decide what you like better. But that would mean a first-run configuration. pi
Comment 75•21 years ago
|
||
The behavior described in comment #73 seems to me the best solution to this. Checking HKCR\http\shell\open\command\ we get to know if it is a browser the one handling images without hardcoding IEXPLORE.EXE.
Comment 76•21 years ago
|
||
*** Bug 213926 has been marked as a duplicate of this bug. ***
Comment 77•21 years ago
|
||
*** Bug 214059 has been marked as a duplicate of this bug. ***
Comment 78•20 years ago
|
||
*** Bug 214629 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Summary: Bad behaviour of automatic reassignment of filetype handler (make 'default browser' steals image file association) → Make 'default browser' shouldn't steal image file associations from image programs
Comment 79•20 years ago
|
||
Related: Bug 214798 - Mozilla should NOT be associated with the .ICO filetype Without reading more than five or so comments (just to see if bug 214798 was a dupe of this bug), its my opinion that we should allow people to add a context menu item to right click of the files as opposed to automatically hijacking the file type. If I repeated something someone already said, I'm sorry. Anyway, that's my 2 cents, but 2 cents doesn't go that far nowadays.
Comment 80•20 years ago
|
||
*** Bug 215073 has been marked as a duplicate of this bug. ***
Comment 81•20 years ago
|
||
Same effect with Firebird. There it's anoying that you don't have any option to disable it within the browser. Instead you have to open the wanted programm and do the association there. Bad! Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1
Comment 82•20 years ago
|
||
For information on Image association see bug 131106.
Comment 83•20 years ago
|
||
Please ignore the previous comment with was mistakenly posted here. It was meant has a reply to a comment on Bug 214054. For that again my apologies.
Comment 84•20 years ago
|
||
To revert any damage that might have been done on this by multiple production machines, you can make a .reg file based on the values the associations in the registry are set back to in Mozilla, and then install that .reg file on all machines. That should be a workaround until this is fixed.
Comment 85•20 years ago
|
||
In my opinion, Firebird shouldn't replace Mozilla Browser until this bug is resolved, you can independantly associate different file types, and Firebird has a way to reverse associations. Otherwise, the reviews of it will be really embarassing.
Comment 86•20 years ago
|
||
Filed bug 216501 for the firebird issue. (Inability to revert after claiming filetypes)
Comment 87•20 years ago
|
||
I really need to pull a new version of source, I just haven't had time -- maybe next week. When I do, I can come up with a quick fix for this as a strict interpretation of the summary of this bug (until we can come to some sort of consensus on what needs to be done long term).
Comment 88•20 years ago
|
||
> To revert any damage that might have been done on this by
> multiple production machines, you can make a .reg file
> based on the values the associations in the registry are
> set back to in Mozilla, and then install that .reg file
> on all machines.
For details see URL in the field above.
pi
Comment 89•20 years ago
|
||
*** Bug 217097 has been marked as a duplicate of this bug. ***
Comment 90•20 years ago
|
||
speaking as another victim who submitted a duplicate of this bug, the automatic, silent hijacking of file type associations is one of the most annoying behaviors common to installers. There is NO REASON for mozilla to take over any file type, and it is inexcusable for it to do so without an explicit dialog saying exactly what it is going to do.
Comment 91•20 years ago
|
||
Dave: no need to add such a SPAM comment. Yes, it's only SPAM and nothing more. attach a patch or be quit. The problem is known and the bug is open.
Comment 92•20 years ago
|
||
A little language gripe: To make the "default browser" is to make the browser the default when a hyperlink is opened (e.g. http://). If I say I would like to make Firebird the default browser it is incorrect for it to also associate any file format based on my answer to that question. It would only be correct if Firebird said "Would you like to associate all supported file types to Firebird?" with keyword *associate*. Even the agressive RealOne Player does not abuse the privilege of being able to associate file formats to itself. During advanced install RealOne asks permission for "general" file types (in our situation we might ask for "Documents (HTML, XML)", "Images (JPEG, PNG)", etc. Mozilla-specific formats like XUL that aren't supported by any other program don't have to be asked about unless Firebird might conflict with, say, full Mozilla. In RealOne you can select and de-select the file-type groups or go into an even more advanced view and pick and choose the extensions you want. Allowing people to make this decision manually is not making things overcomplicated, as long as it's not mandatory.
Comment 93•20 years ago
|
||
Skewer: Why do you add a useless spam comment ? You don't add new informations. Please never add such useless comments in a bug. reread my last comment "The problem is known and the bug is open." FYI: The current owner doesn't work on Mozilla and this will not be fixed unless someone else attaches a patch.
Comment 94•20 years ago
|
||
Skewer: Why do you add a useless spam comment ? You don't add new informations. Please never add such useless comments in a bug. reread my last comment "The problem is known and the bug is open." FYI: The current owner doesn't work on Mozilla and this will not be fixed unless someone else attaches a patch. Your griping about it *in the bug* improves the alleged situation how?
Comment 95•20 years ago
|
||
*** Bug 219123 has been marked as a duplicate of this bug. ***
Comment 96•20 years ago
|
||
Nominating as blocker for 1.5... this is a regression in the installer and makes Mozilla a very bad citizen.
Flags: blocking1.5?
Comment 97•20 years ago
|
||
Regression ? That's wrong and this is a very old bug !
Comment 98•20 years ago
|
||
This hasn't blocked any other release. Why start now.
Flags: blocking1.5? → blocking1.5-
Comment 99•20 years ago
|
||
Because it is a very annoying and embarrasing bug that makes mozilla look bad. The solution proposed in comment #73 looks very reasonable.
Comment 100•20 years ago
|
||
There is no attached patch. 1.5 is already in release candidated and this is not a blocker. I don't know if pmac or law are even still around. I'll take QA if necessary.
Comment 101•20 years ago
|
||
You are right, I misread 1.5 as 1.6. However, this bug definitely needs some love. :(
Comment 102•20 years ago
|
||
alanjstr: Don't touch the blocker flags again. You are right but you don't decide that ! Resetting to "blocking1.5?" Why do you want to takle the QA for a bug that doesn't need QA ?
Flags: blocking1.5- → blocking1.5?
Comment 103•20 years ago
|
||
As a simple solution that should be very easy to implement, why not just simply drop *everything* in Mozilla and Firebird that could possibly cause Mozilla or Firebird to associate itself with images ? In other words, simplify the procedure in comment #73 to: a) find out which application is servicing the "http" protocol. http_handler = get_appname_from("HKCR\http\shell\open\command\@"); b) for $proto in (http,https,ftp,gopher,appliction/http etc) { handler = get_appname_from($proto); if (user_said_yes && handler == http_handler) set_mozilla_as_default_handler($proto). else leave_existing_mimetype/protocol_handler. } Mozilla is *very* ill-suited for use as anything other than a web browser and a mail/news app - it has no business pretending to be an image viewer. If someone, for whatever strange reason, wants to use Mozilla as an image viewer, then let that one particular user manually set his file associations by using the tools provided by his operating system. If Mozilla is going to associate itself with images merely because it *can* display an image, then there is no logical reason to stop there - it should also steal associations for text files and anything else it can display. Clearly it is absurd for Mozilla to associate itself with text files when you make it the default browser - yet we for some reason let Mozilla do something equally absurd when it comes to image files.
Comment 104•20 years ago
|
||
*** Bug 222659 has been marked as a duplicate of this bug. ***
Comment 105•20 years ago
|
||
Makes sense to me :)
Updated•20 years ago
|
Flags: blocking1.5?
Reporter | ||
Comment 106•20 years ago
|
||
> why not just simply drop *everything* in Mozilla and Firebird that could > possibly cause Mozilla or Firebird to associate itself with (file extensions)? because on a standard windows installation, .jpg, .jpeg, .jfif, .gif, .png are associated with a browser. If moz is taking over "things" from that browser it do so consistantly. > Mozilla is *very* ill-suited for use as anything other than a web browser and > a mail/news app - it has no business pretending to be an image viewer. correct. While the pseudo-code in comment #73 certainly can be simplified, the route you suggest (simply not handling _any_ extension), is not an option. Not only due to the reason mentioned above, but also because of .htm[l], .js, .xml etc.
Comment 107•20 years ago
|
||
> because on a standard windows installation, .jpg, .jpeg,
> .jfif, .gif, .png are associated with a browser. If moz
> is taking over "things" from that browser it do so
> consistantly.
Just last week I have seen a fresh Win2k installation.
Pictures were associated to some windows picture viewer, not
to IE. And that's what I recall from windows versions.
The solution would be either
a) add a second checkmark for image types or
b) make the image types only available via the preferences menu.
pi
Reporter | ||
Comment 108•20 years ago
|
||
*sigh* According to comment #73: "Make mozilla my default browser" => take over anything handled by a browser, BUT NOTHING ELSE. In other words, _anything_that_is_not_handled_by_a_browser_is_NOT_touched_by mozilla, and that includes: > Pictures were associated to some windows picture viewer So... > a) add a second checkmark for image types or > b) make the image types only available via the preferences menu. ... are uneccessary because those image types that are handled by mozilla were the ones previously handled by another browser (ergo all covered by "make it default browser").
Comment 109•20 years ago
|
||
How do you tell an associated program is a browser? pi
Reporter | ||
Comment 110•20 years ago
|
||
> How do you tell an associated program is a browser? simply by comparing the path of the program associated with <image file extn> to the path of the program associated with "http". comment #73 tells you how to get the filename of the app that is the browser: http_handler = get_reg_string("HKCR\http\shell\open\command\@"); The same logic to find out which application is servicing (say) .gif is: gif_handler = get_reg_string("HKCR\" + get_reg_string("HKCR\.gif\@") + "shell\open\command\@" ) Compare the two paths: if (gif_handler <> http_handler) message_box(".gif IS NOT being handled by browser"); else message_box(".gif IS being handled by browser");
Comment 111•20 years ago
|
||
> simply by comparing the path of the program associated with <image file extn>
> to the path of the program associated with "http".
Note: Just because some other program may have hijacked image file associations
is no reason for Mozilla to do so. Do we want to perpetuate something that's wrong?
Not to mention the fact that IE, being part of the filesystem, loads much faster
than does Mozilla. If IE is set to display images, the user may wish for this
to continue, while having actual Web pages displayed in Mozilla.
I don't see any way that we can assume that just because another browser is
currently assigned to view image files that that gives us ANY permission to take
over from it.
Comment 112•20 years ago
|
||
>simply by comparing the path of the program associated with <image file extn>
>to the path of the program associated with "http".
What if IE is associated with images, yet Opera is associated with HTTP? Images
are still associated with a browser, but not with the default browser.
Also, Win98 and previous, afaik, do not come with picture and fax viewer. I
might be wrong, though, or they might have provided it in an update for IE.
Either way, we can't rely on a Windows installation having picture and fax
viewer, nor should we even attempt to take associations of anything but http
because of the risks. Therefore, people either need the ability to add the
associations in preferences, we need to provide an extension to mozilla, or we
need to just forget about it and force the user to do it themselves for images
and other formats which could be quite tedious for a user and make them ask,
"Why is it not settable in an easier fashion". If we settle for the latter, we
better guarantee Mozilla shows up in the programs list you see when you want to
associate a file when its installed, or the user will have to browser for the
MozillaFirebird binary.
I think the best negotiation would be to provide this in an extension maintained
by Mozilla.org but not distributed with the binary, but instead on the site.
The issue of how we'll combine this with the behavior of showing the dialog
asking if you want to set Mozilla as the default browser is simple. We don't
allow fine-tuning without the extension. When you click yes, it just associates
with HTTP. All you get in the preferences is the button to unassociate. The
extension (which would replace the button with an "advanced..." button is
another bug.
With a new patch that does nothing but sets it as handler for http, we can
relegate the more advanced behavior to a bug asking for the creation of an
extension, check this fix in, mark it fixed, and not look bad when
MozillaFirebird becomes 1.0 and this still isn't fixed. This is a major issue in
many peoples' opinions.
In summary:
* We should fix this simply by associating with http and nothing else.
* We should provide a button in preference to undo the association
* Any talk of extending this behavior goes to another bug so we can get this in.
Anyway, that's my opinion of the direction we should take.
Comment 113•20 years ago
|
||
As a submitter of a dup of this bug, I'd agree with Brian Bober's suggestion: as a temporary fix, just make sure that mozilla grabs HTML files for itself, and nothing else. If some intelligence needs to go behind the "Yes" button on the defualt browser dialogue, develop it under another bug. Surely something needs to be done about a bug that has had 24 dups, 30-odd votes and has been open for over a year and a half? How much debate does a bug need, when the complaints keep coming in? After all, we're talking about *first impressions* here - for someone that's never used Mozilla before, grabbing file types that they did not request nor want might just be enough for them to uninstall immediately and swear about Mozilla (not in a good way) to everyone they meet?
Comment 114•20 years ago
|
||
*** Bug 224299 has been marked as a duplicate of this bug. ***
Comment 115•20 years ago
|
||
Im am submitter of above dupe an I filed it for *Firebird* *not* Mozilla. I have to underline this, because in several comments, people said somethng like "Mozilla is not for end-users, so this is not critical to Mozilla.org". But I filed it for Firebird because Firebird *is* for end-users and therefore very critical for me. Here is what I wrote concerning the dupe: -------------- When you set Firebird as default browser in Windows, it is associated with all the image files it can read. There is NO way to stop that. This is very bad for people who have seperate image viewers or image manipulation programs installed. They have to go and reassociate these programs with their files again. Especially unexperienced users consider this a "blocker" and hit "uninstall" faster than you could explain them how to fix the problem. If we *are* targeting end-users with Firebird, we *have* to make this an *option* to be activated *seperately* or at least *ask* if Firebird should do that. I mark this "critical" because basicly there is data lost, system preferences to be precise. -------------- So I stongly agree with comment #26, and strongly *disagree* with #28. For Firebird (has it even UI to reverse that? I don't use Windows very often any more), which is for end-users, it is a show-stop.
Comment 116•20 years ago
|
||
> in several comments, people said something like
> "Mozilla is not for end-users
Which, given The Mozilla Foundation's new philosophy, is now also incorrect.
Also, I'm reopening your Firebird bug. There's sufficient difference between
the two products that it shouldn't have been marked as a dupe.
Comment 117•20 years ago
|
||
Law isn't going to do this. Taking, scheduling.
Assignee: law → bugs
Priority: -- → P3
Whiteboard: firebird0.9
Target Milestone: --- → mozilla1.7alpha
Comment 118•20 years ago
|
||
*** Bug 229834 has been marked as a duplicate of this bug. ***
Comment 119•20 years ago
|
||
Try Preferences > Advanced > System. This is a little improvement, but still, I think maybe this dialog should be displayed to the user for the time being? And I'd suggest an icon redo 'coz all icons are the same at the moment.
Comment 120•20 years ago
|
||
Comment 121•20 years ago
|
||
Um, why did you remove the chrome protocol?
Comment 122•20 years ago
|
||
Comment on attachment 139348 [details] [diff] [review] only take "default browser" types for Seamonkey/Firebird by default http://lxr.mozilla.org/mozilla/source/xpfe/components/winhooks/nsSetDefaultBrow ser.js#78 specifies six things as "default browser" settings which are always set, but this part of winhooks makes a larger number default to on. This will not affect existing Mozilla installations, as those installations may modify the rest of this list in the advanced prefs, and future "set as default" actions use those settings. The exception is in the Prefs dialog button, where it will force these six on (as it should). For new users, however, we shouldn't take these by default. Other than win 9x/ME/early 2k versions, Windows has an image viewer that beats Mozilla. Worst case is that those users have IE for their images, and if they want to change it badly enough they do it via the prefs panel. In Firebird, Ben already said that we aren't going to have UI for this, if they want the image associations they can do it themselves via the Windows interface. We may want to consider for Firebird whether we should explicitly force the images off in the Set As Default Browser button so that existing users aren't affected. This needs to happen here as the default browser dialog uses these values, so product-specific changes won't be enough.
Attachment #139348 -
Flags: superreview?(bugs)
Comment 123•20 years ago
|
||
And why is Gopher (bug 194220) removed?
Comment 124•20 years ago
|
||
chrome:// URLs don't work without the chrome switch. There really isn't any reason to register it unless you're planning on emailing chrome links... And the gopher meta bug gives a terrible impression of the current state of gopher. benc suggested it might be better to just remove it from the trunk. If someone has an existing gopher program, they're probably better off keeping it.
Comment 125•20 years ago
|
||
My patch for bug 160141 addresses all of the problems with chrome protocols, etc. I'd recommend updating that patch to tip except change the defaults and don't include the chrome for mail, etc. The only thing that needs to be done after that for the other bug to be fixed is for new chrome to be added, separated into extensions (one for mail, one for chat, etc.)
Updated•20 years ago
|
Keywords: conversion
Comment 126•20 years ago
|
||
Comment on attachment 139348 [details] [diff] [review] only take "default browser" types for Seamonkey/Firebird by default forked for Firefox, if someone wants to take this and get reviews and land it, go ahead
Attachment #139348 -
Flags: superreview?(bugs)
Updated•20 years ago
|
Keywords: conversion
Comment 127•20 years ago
|
||
*** Bug 236632 has been marked as a duplicate of this bug. ***
Comment 128•20 years ago
|
||
When dealing with image files the option shouldn't be Open. It is far too vague. It should be "View" in the context menu and that should be associated with mozilla ie you'd want to VIEW an image because you cannot edit it with moz
Comment 129•20 years ago
|
||
When dealing with image files the option shouldn't be Open. It is far too vague. It should be "View" in the context menu and that should be associated with mozilla ie you'd want to VIEW an image because you cannot edit it with moz
Comment 130•20 years ago
|
||
Didn't Blake already land this?
Comment 131•20 years ago
|
||
As mentioned in comment 126, the issue has been fixed in Firefox only, by forking the file. To fix it in Seamonkey, which is what the bug was originally about, it still needs someone to get reviews and land it.
Attachment #139348 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 132•20 years ago
|
||
Comment on attachment 139348 [details] [diff] [review] only take "default browser" types for Seamonkey/Firebird by default (In reply to comment #124) >chrome:// URLs don't work without the chrome switch. Which they do add... so I'll need a better argument not to remove chrome, and also xul, while you're there...
Comment 133•20 years ago
|
||
*** Bug 239520 has been marked as a duplicate of this bug. ***
Comment 134•20 years ago
|
||
I've created a new bug that may be of some interest to those of you involved with this bug, to do with choosing file associations. It is Bug #244257.
Comment 135•20 years ago
|
||
*** Bug 244260 has been marked as a duplicate of this bug. ***
Comment 136•20 years ago
|
||
*** Bug 245355 has been marked as a duplicate of this bug. ***
Comment 137•20 years ago
|
||
*** Bug 247780 has been marked as a duplicate of this bug. ***
Comment 138•20 years ago
|
||
I think this one is fixed in firefox 0.9.
Comment 139•20 years ago
|
||
It didn't occur when I installed FireFox 0.9 on my Windows 2000 machine
Comment 140•20 years ago
|
||
(In reply to comment #138) > I think this one is fixed in firefox 0.9. (In reply to comment #139) > It didn't occur when I installed FireFox 0.9 on my Windows 2000 machine This is a Mozilla suite bug, Bug 216432 was the Firefox bug
Comment 141•19 years ago
|
||
I just installed Mozilla 1.8 a2 and it didn't take my image associations away from Irfanview.
Comment 142•19 years ago
|
||
still happens with the latest trunk nightly, if you make it the default. this is only about the suite now though, so reassigning back to default.
Assignee: bugs → jag
QA Contact: pmac → pawyskoczka
Whiteboard: firebird0.9
Target Milestone: mozilla1.7alpha → ---
Comment 143•19 years ago
|
||
Please change the OS designation to Windows XP or All, as it is not just an NT bug. This bug is a Windows XP bug for Mozilla 1.7.3
Comment 144•19 years ago
|
||
It doesn't make a difference. It's not all since it doesn't affect Linux and Macintosh or FreeBSD. Currently there is no WIN* platform choice because that would be abused. Windows NT is actually more global than XP since it covers NT4, NT5 (Windows 2000), and NT5.1 (Windows XP)
Updated•19 years ago
|
Product: Core → Mozilla Application Suite
Comment 145•19 years ago
|
||
*** Bug 275423 has been marked as a duplicate of this bug. ***
Comment 146•19 years ago
|
||
Looks like everyone would agree to a version of the attached patch that just breaks Mozilla's habit to steal the *image* file associations, right? Perhaps we should just do this and move the discussion about chrome, XUL and gopher to other bugs. This bug is only about image file types anyway. I would do this, but I don't have a Windows installation to test a patch to this effect. Perhaps mcsmurf wants to help? :-)
Assignee | ||
Comment 147•19 years ago
|
||
This bug is too big for me ;-).
Comment 148•19 years ago
|
||
I would like to add the comment that this still happens in the latest 1.7.6 release. I upgraded my brother's system this past weekend, and later he called to say that his images weren't coming up right anymore. Turned out Mozilla had once again stolen the file assocations away from IrfanView. And he gets very cranky when his system changes. As this was an *upgrade* from a prior version, it should have respected the existing settings, and not pulled a "microsoft" by taking what it pleased.
Comment 149•19 years ago
|
||
Current night builds have this bug too.
Comment 150•19 years ago
|
||
(In reply to comment #149) > Current night builds have this bug too. Install of 1.7.7, as an upgrade from 1.7.3 has stolen associations for .gif .png .jfif .jpe .xbm Despite anti file association stealing features in my image viewer. This has been around long enough. If it cannot be fixed in a technically sophisticated way, then it should be fixed by brute force and the awckwardness accepted - that is by not associating image files with Mozilla at all, even when they are associated with the former default browser. In other words, Mozilla would be a better product if it did not steal these file associations, even if that means it failed to pick up file associations which were assigned to a former default browser or have not been assigned at all. Further - this three year old issue should be considered a blocking issue for 1.8. I man not know how to read that information at the header for this looong series, but the blank box would appear to indicate that it is not considered as a blocKing issue. It should be.... THREE YEARS?
Assignee | ||
Comment 151•19 years ago
|
||
*** Bug 295021 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 152•19 years ago
|
||
Attachment #139348 -
Attachment is obsolete: true
Attachment #184578 -
Flags: review?(neil.parkwaycc.co.uk)
Assignee | ||
Updated•19 years ago
|
Attachment #139348 -
Flags: review?(neil.parkwaycc.co.uk)
Updated•19 years ago
|
Attachment #184578 -
Flags: review?(neil.parkwaycc.co.uk) → review+
Assignee | ||
Updated•19 years ago
|
Attachment #184578 -
Flags: superreview?(jag)
Comment 153•19 years ago
|
||
*** Bug 124136 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
Attachment #184578 -
Flags: superreview?(jag) → superreview+
Assignee | ||
Updated•19 years ago
|
Attachment #184578 -
Flags: approval1.8b3?
Updated•19 years ago
|
Attachment #184578 -
Flags: approval1.8b3? → approval1.8b3+
Comment 154•19 years ago
|
||
Checking in nsWindowsHooks.cpp; /cvsroot/mozilla/xpfe/components/winhooks/nsWindowsHooks.cpp,v <-- nsWindowsHooks.cpp new revision: 1.62; previous revision: 1.61 done
Assignee: jag → bugzilla
Frank--mark this fixed?
Assignee | ||
Comment 156•19 years ago
|
||
yes :), wanted to check if anything else (like Installer) sets image permissions, but doesn't seem so.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Verified FIXED using build 2005-09-11-05 on Windows XP SeaMonkey trunk (stub installer).
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•