Closed Bug 285416 Opened 20 years ago Closed 20 years ago

Access to Firefox Options from Start Menu broken

Categories

(Firefox :: Shell Integration, defect, P1)

x86
Windows XP
defect

Tracking

()

RESOLVED FIXED
Firefox1.5

People

(Reporter: ali, Assigned: Gavin)

Details

(Keywords: regression)

Attachments

(2 files, 4 obsolete files)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050308
Firefox/1.0+

If Firefox is your default browser on Windows XP, it will show in the top left
of the Start Menu. You can right click on it, and find an option called 'Firefox
Options'. Clicking this used to bring up the Firefox options, but now brings a
tiny window without a title (see forthcoming screenshot). This is probably a
regression from the Prefwindow V checkin.

Steps to repro:

1. Have Firefox be your default browser
2. Click on Start Menu
3. Right click on Firefox in top left of Start Menu
4. Choose 'Firefox Options'

Expected:

Brings up Firefox options

Actual:

Tiny nameless window pops up
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1? → blocking-aviary1.1+
I have a patch for this coming up.
Assignee: bugs → gavin.sharp
Target Milestone: --- → Firefox1.1
Requirements for this patch:

Has to obviously fix the shellservice to set the new URL.

Has to migrate obsolete registry settings during default browser checking,
without  user interaction if its the only change.
(In reply to comment #3)
> Requirements for this patch:
> Has to obviously fix the shellservice to set the new URL.

I thought it would be better to introduce a "-preferences" parameter, to
eliminate the need to hardcode the value and prevent us from having to do such
cleanup in the future.

> Has to migrate obsolete registry settings during default browser checking,
> without user interaction if its the only change.

Is default browser checking done at each startup regardless of the "ask me..."
pref? This is the part I haven't gotten to yet, I should be able to look into it
tonight.
Good point, but if you add a command-line handler, it'll have to work on all
platforms, and I'm not sure how well that'd work on Linux with an open app.
This adds a "-preferences" handler to remove the need to hardcode the chrome
URL in the registry, and makes the appropriate change to the default browser
code. It also makes a change to another caller that has the old pref URL
hardcoded.

This doesn't fix cases where the old registry key is already set, which would
be most existing installs I assume.
Attachment #177818 - Flags: review?(bugs)
Status: NEW → ASSIGNED
Priority: -- → P1
Whiteboard: [patch-r?]
Priority: P1 → P2
Whiteboard: [patch-r?] → [patch-r?][wip]
Attached patch Patch v2 (obsolete) — Splinter Review
This patch:
> Adds the -preferences command line param so that it's not necessary to hard
code the chrome URL
> Checks for the old pref URL and handles it separately
Attachment #177818 - Attachment is obsolete: true
Attachment #180211 - Flags: review?(mconnor)
Attachment #177818 - Flags: review?(bugs)
Priority: P2 → P1
Whiteboard: [patch-r?][wip] → [patch-r?]
Attachment #180211 - Attachment is obsolete: true
Attachment #180211 - Flags: review?(mconnor)
Attached patch Patch v3 (obsolete) — Splinter Review
The last patch had some problems with focusing the dialog when a window was
already open. I'll do some more testing before asking for review, but I think
that this should work in all cases.
Whiteboard: [patch-r?]
Attached patch Patch v4 (obsolete) — Splinter Review
This has been tested on Windows and works fine in all situations I can think of
(options window already opened, browser already opened, no browser opened, etc)
using both "-preferences" and "-chrome chrome://browser/content/pref/pref.xul"
(the old pref URL). It shouldn't be any different on Mac/Unix, but I haven't
tested there.
Attachment #180339 - Attachment is obsolete: true
Attachment #180860 - Flags: review?(mconnor)
This has been tested on Windows and works fine in all situations I can think of
(options window already opened, browser already opened, no browser opened, etc)
using both "-preferences" and "-chrome chrome://browser/content/pref/pref.xul"
(the old pref URL). It shouldn't be any different on Mac/Unix, but I haven't
tested there.
Attachment #180860 - Attachment is obsolete: true
Attachment #180861 - Flags: review?(mconnor)
Attachment #180860 - Flags: review?(mconnor)
Whiteboard: [patch-r?]
Comment on attachment 180861 [details] [diff] [review]
Patch v4 (corrected)

r=me

requesting approval (rather late) this should be fairly safe, and fixes
something that'll be obviously broken otherwise.
Attachment #180861 - Flags: review?(mconnor)
Attachment #180861 - Flags: review+
Attachment #180861 - Flags: approval-aviary1.0.4?
Comment on attachment 180861 [details] [diff] [review]
Patch v4 (corrected)

bloody hell.
Attachment #180861 - Flags: approval-aviary1.0.4? → approval-aviary1.1a?
Comment on attachment 180861 [details] [diff] [review]
Patch v4 (corrected)

a=asa
Attachment #180861 - Flags: approval-aviary1.1a? → approval-aviary1.1a+
Whiteboard: [patch-r?] → [patch-r+][checkin needed]
Checked in by mconnor.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Whiteboard: [patch-r+][checkin needed]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: