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)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: cyp, Assigned: mcsmurf)

References

(
URL
)

Details

(Keywords: helpwanted)

Attachments

(1 file, 1 obsolete file)

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

Sorry, didn't mean to sound condescending. Install details follow...
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.


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


*** Bug 131110 has been marked as a duplicate of this bug. ***
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
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?
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
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.
--> qa tpreston@netscape.com
QA Contact: paw → tpreston
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 );
    }
}



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

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.
*** Bug 133909 has been marked as a duplicate of this bug. ***
*** Bug 135564 has been marked as a duplicate of this bug. ***
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.
er, "In the Installer case simplifying thins is not really an issue, as real
people don't use those." -> s/Installer/zip build/ :)
*** Bug 143621 has been marked as a duplicate of this bug. ***
*** Bug 144417 has been marked as a duplicate of this bug. ***
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.
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
*** Bug 149464 has been marked as a duplicate of this bug. ***
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.

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

mozilla does this sometimes. I'm not able to reproduce this 100%, but sometimes
JPG's are taken over by Mozilla...:(
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.
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
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.  
*** Bug 150357 has been marked as a duplicate of this bug. ***
*** Bug 153919 has been marked as a duplicate of this bug. ***
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).
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
*** Bug 156740 has been marked as a duplicate of this bug. ***
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 !
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.

> 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.
>> 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)
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.
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)
*** Bug 149682 has been marked as a duplicate of this bug. ***
*** Bug 164948 has been marked as a duplicate of this bug. ***
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
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
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.

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.
*** Bug 186446 has been marked as a duplicate of this bug. ***
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
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
QA Contact: tpreston → pmac
*** Bug 193600 has been marked as a duplicate of this bug. ***
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).
Not a bad idea.  But someone needs to do it....
Keywords: helpwanted
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
URL: http://piology.org/mozilla/of-the-day...
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?
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).
Flags: blocking1.3? → blocking1.3-
Keywords: nsbeta1- → nsbeta1
My apologies about changing the nsbeta1- keyword - my mistake. Reverting now.
Keywords: nsbeta1 → nsbeta1-
*** Bug 197390 has been marked as a duplicate of this bug. ***
*** Bug 197630 has been marked as a duplicate of this bug. ***
*** Bug 207370 has been marked as a duplicate of this bug. ***
*** Bug 209743 has been marked as a duplicate of this bug. ***
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.
If there is a consensus on *what* the fix needs to be, I'll look at implementing it.
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?

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

> 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.)
> > 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)
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_?
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 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
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.
*** Bug 213926 has been marked as a duplicate of this bug. ***
*** Bug 214059 has been marked as a duplicate of this bug. ***
*** Bug 214629 has been marked as a duplicate of this bug. ***
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
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.
*** Bug 215073 has been marked as a duplicate of this bug. ***
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
For information on Image association see bug 131106.
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.
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.
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.
Filed bug 216501 for the firebird issue.
(Inability to revert after claiming filetypes)

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).
> 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
*** Bug 217097 has been marked as a duplicate of this bug. ***
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.

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.
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.
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.
  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?
*** Bug 219123 has been marked as a duplicate of this bug. ***
Nominating as blocker for 1.5... this is a regression in the installer and makes
Mozilla a very bad citizen.
Flags: blocking1.5?
Regression ?
That's wrong and this is a very old bug !

This hasn't blocked any other release.  Why start now.
Flags: blocking1.5? → blocking1.5-
Because it is a very annoying and embarrasing bug that makes mozilla look bad.

The solution proposed in comment #73 looks very reasonable.
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.
You are right, I misread 1.5 as 1.6.
However, this bug definitely needs some love. :(
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?
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.
*** Bug 222659 has been marked as a duplicate of this bug. ***
Makes sense to me :)
Flags: blocking1.5?
> 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.
> 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
*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").


How do you tell an associated program is a browser?

pi
> 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");


> 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.
>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.
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?
*** Bug 224299 has been marked as a duplicate of this bug. ***
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.
> 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.
Blocks: 224299
No longer blocks: 224299
Law isn't going to do this. Taking, scheduling.
Assignee: law → bugs
Priority: -- → P3
Whiteboard: firebird0.9
Target Milestone: --- → mozilla1.7alpha
*** Bug 229834 has been marked as a duplicate of this bug. ***
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.
Blocks: 230922
Um, why did you remove the chrome protocol?
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)
And why is Gopher (bug 194220) removed?
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.
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.)
Blocks: majorbugs
Keywords: conversion
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)
Keywords: conversion
*** Bug 236632 has been marked as a duplicate of this bug. ***
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
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
Didn't Blake already land this?
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 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...
*** Bug 239520 has been marked as a duplicate of this bug. ***
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.
*** Bug 244260 has been marked as a duplicate of this bug. ***
*** Bug 245355 has been marked as a duplicate of this bug. ***
*** Bug 247780 has been marked as a duplicate of this bug. ***
I think this one is fixed in firefox 0.9.
It didn't occur when I installed FireFox 0.9 on my Windows 2000 machine
(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


I just installed Mozilla 1.8 a2 and it didn't take my image associations away
from Irfanview.
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 → ---
No longer blocks: 230922
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


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)
Product: Core → Mozilla Application Suite
*** Bug 275423 has been marked as a duplicate of this bug. ***
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? :-)
This bug is too big for me ;-).
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.  
Current night builds have this bug too.
(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?  
*** Bug 295021 has been marked as a duplicate of this bug. ***
Attached patch Patch — — Splinter Review 

        Attachment #139348 -
        Attachment is obsolete: true

        Attachment #184578 -
        Flags: review?(neil.parkwaycc.co.uk)

    
  

        Attachment #139348 -
        Flags: review?(neil.parkwaycc.co.uk)

    
  

        Attachment #184578 -
        Flags: review?(neil.parkwaycc.co.uk) → review+

    
  

        Attachment #184578 -
        Flags: superreview?(jag)

    
  
No longer blocks: majorbugs

    
    

    
  
*** Bug 124136 has been marked as a duplicate of this bug. ***

    
  

        Attachment #184578 -
        Flags: superreview?(jag) → superreview+

    
  

        Attachment #184578 -
        Flags: approval1.8b3?

    
  

        Attachment #184578 -
        Flags: approval1.8b3? → approval1.8b3+

    
    

    
  
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

    
    

    
  
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.