Closed Bug 88739 Opened 22 years ago Closed 18 years ago

F1 on Win/*nix, Cmd+? on Mac key doesn't bring up help

Categories

(SeaMonkey :: Help Documentation, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey1.0alpha

People

(Reporter: AriB, Assigned: stefanh)

References

Details

Attachments

(2 files, 8 obsolete files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2+) Gecko/20010701
BuildID:    2001070108



Reproducible: Always
Steps to Reproduce:
1. Start up mozilla and wait for home page to finish loading
2. Press the function key F1 (standard Help key on Windows)


Actual Results:  Nothing

Expected Results:  Bring up Help Window
dupe of bug 55305 or bug 46226 ?
No. It could depend on 55305 but in order for this bug to be fixed, F1 must call
up Help Contents and should be listed in the menu just like NS 4.7x did.
46226 is about context sensitive help which is completely different than calling
Help Contents from anywhere
I can't find a dupe. marking new
Status: UNCONFIRMED → NEW
Ever confirmed: true
I am on this one. Just to figure things out, I've gotten a thing working where I 
have Ctrl+8 opening the help window (modeled after and stuck in the 
tasksOverlay stuff), but how do I bind the <F1> key? 

I guess I don't understand the relationship between this key and, say, the keys 
defined in:
http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/locale/en-US/keys.
properties

Is there a precedent in the UI for using this kind of key as opposed to the 
accel+somekey combo?
Status: NEW → ASSIGNED
Hello! Just got it:
<key id="key_help" keycode="VK_F1" command="toHelp();" />
Now just trying to figure out where I should put this. Have it now in 
tasksOverlay, though that set of files seems more particular to the Tasks menu 
itself. utilityOverlay?

F1 is the standard Windows help key. It's NS 4.7x too
Attached patch adding f1 key to help (obsolete) — Splinter Review
Ian, let's get this one in on the trunk (once you get an r and sr) and see if
it's OK---maybe Terri can help verify. Once it's deemed OK, we'll check it in on
the branch.

Adding nsBranch keyword.
Keywords: nsBranch
Adding blake for review: F1 launching help.
Why isn't the menuitem using the command also?
blake & walk84
Doesn't seem to work when I hook up the menu. It may be something to do with the 
id's being used, the possibility that there is some name stomping going on with 
something as basic as "help" or "key_help" or something, but for whatever 
reason, doing
<menuitem key="key_help" command="Help:open" ...> gets me nothing from the menu 
(though <F1> still works fine). Feel like OK'ing it anyway?
r=walk84
It's because you're not including the command along with the menuitem (in 
the files that this overlay overlays onto)...that said, I don't see how the key 
works either...
Updated patch so that the menuitem uses the command and key as it should. But 
this doesn't work (!), and it's because, as Blake said, I am not getting the 
command into the target file. How do I do this? 

In utilityOverlay.xul, there seem to be lots of individual keys and commands, 
but few keysets and commandsets, into which I had hoped to overlay the "key_set" 
and "Help:open" stuff I have in the overlay. In fact, one comment says the keys 
are "there for show" because the real bindings are defined in the 
platformBindings file.

Note that on linux, the menuitem seemed to pick up the key and display it as 
part of the label, where on win32 it doesn't show it (and also doesn't execute 
the command). hmmm...

Need help.


You get to put <keyset id="helpKeys"/> and <commandset id="helpcommandset"/> in 
every in every file that helpMenuOverlay overlays onto.  Isn't XUL fun!?

(Note that, while the key has to be in the keyset, the command 
doesn't...however, if you're going to keep it in the commandset, please 
capitalize the 'C')

Have no fear, though, whenever Ben (or I, but it's assigned to him ;) gets 
around to doing the window and dialog bindings, this will be a built-in feature 
that you won't have to worry about.
Wow, that's a bummer that you can't simply overlay keys and commands like you do 
the menuitems themselves. It looks like there are various ways to go about 
getting them put into the target files. I will attach a patch of how I hope to 
do this in one of the components, and with this sort of addition to the 
contents.rdf file in the help dir that registers the overlay:

  <!-- Declare overlay points used in this package -->
  <RDF:Seq about="urn:mozilla:overlays">
    <RDF:li resource="chrome://communicator/content/utilityOverlay.xul"/>
    <RDF:li resource="chrome://messenger/content/messenger.xul"/>
    <RDF:li resource="chrome://composer/content/editor.xul"/>
  </RDF:Seq>

  <RDF:Seq about="chrome://composer/content/editor.xul">
    <RDF:li>chrome://help/content/helpMenuOverlay.xul</RDF:li>
  </RDF:Seq>
  ...etc..

Blake, when you have a moment, let me know if this is what you meant--if this is 
good form. Should I explicitly <?xul-overlay> the help file instead? And who 
else should get this besides the browser, the composer, and the messenger? 
addressbook? Thanks a lot
Note that this is a platform-specific bug.  On Mac, F1 is typically defined as 
Undo but a user can reset it.  The fix for this bug should be platform specific.

While we're at it, why doesn't the Help key on my Macintosh keyboard set to bring 
up help?  Solaris users also have a help key.
Keywords: pp
Updating milestone to 0.9.4
Target Milestone: --- → mozilla0.9.4
Ian - Is this a stop ship for 0.9.4. If it is, please have your manager mark
this as nsbranch+.
adding nsbranch+ on rudman's behalf (and per triage with him before his
vacation). I have the fix for this mostly in hand (viz the attachments here),
and it's an integral feature of the help system.
Keywords: nsbranchnsbranch+
Regarding the proposed patch above, I don't agree that a Windows-specific 
keybinding should be added in a general location.  I would prefer to see a 
Windows-specific fix.
Kathy
I have been poking around for a good platform-specific DTD for doing key
bindings (e.g. keycode=VK_F1 vs. keycode=mac help button) and not finding
anything. This seems like something we should already have done, and I realize
it's sort of late in the game to entertain changes of this nature, but do you
think we could cook up a new DTD for doing this sort of platform key binding
stuff. Like a platform_keys.dtd in global/locale?

I could imagine this being useful in a number of other cases besides the help
system, which needs it pretty bad. 

cc'ing jag
Aaron
I was thinking about doing platform-specific keys.properties, and I understand
you are the one to talk to about this. Help needs F1 on windows but not on mac,
where I gather F1 gets used for other things. It seems like there would be some
other cases for using this platform split. 

Can you let me know whether this is doable and a good idea? Could you help me
push this through if it is something that would be of value?
Thanks, i.
0.9.4 is out the door.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Ian, use Cmd+? for contextual help on Mac, F1 on all other platforms.
Also support the help key on mac and sparc keyboards that have them :-).  See 
some bug assigned to me for info about the sparc stuff.
Adding correctness Status Whiteboard, correct/expected behavior does not occur.
Whiteboard: [correctness]
Why is this a stop-ship for this release?  6.1 went out without this fix.

No reviews, patch is not complete (doesn't address platform issues.)

PDT- unless and until these issues can be resolved.
Whiteboard: [correctness] → [correctness] PDT-
Futuring to 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Blocks: 107066
Keywords: nsbranch+
NOTE: This is very useful, but only if it brings up contextual help for the
currently focused item.
Summary: F1 key doesn't bring up help → F1 key doesn't bring up contextual help
Resetting milestone.
Target Milestone: mozilla0.9.6 → mozilla0.9.8
Futuring to 1.0
Target Milestone: mozilla0.9.8 → mozilla1.0
will this be fixed for 1.0? i was confused by the "futuring" comment.
Ian, I don't remember if this is In or Out for this release....Your call.
I think it's out. Unless I can get some more help. It turns out that there are
some issues with using the F1 key on the mac, and we don't yet have any good way
of handling this for different platforms, where the help key could be mapped to
F1 on unix and windows but something else on the mac
we should have a good way. we do have platform*bindings files.

the big question might be do we want to bind it to VK_HELP and then have 
bindings which control what maps to that, or do we want to directly go from 
VK_F1 to show_help()
That would be platformDialogOverlay.xul for dialogs, right?  But I'm unsure of
what to use for normal windows.  There's platformHTMLBindings, but when talking
about bug 71832 Blake told me that would only work if <browser> had focus.

As for the mapping, I think that our standard lately has been to register a
command and then map a key to that command, instead of using oncommand.  I don't
think we need the intermediate step of going to VK_HELP, do we?
for mac we kind of do because the key is labeled help.  on this (mac) usb 
keyboard it's also the insert button.  if I saw VK_INSERT bound to show_help() 
i'd probably scream.
timeless--currently the mac widget code maps the "ins/help" key to VK_INSERT

http://lxr.mozilla.org/seamonkey/source/widget/src/mac/nsMacEventHandler.cpp#820

We could easily change it to map it to VK_HELP instead.
removing PDT grafitti. 

looks like we got a patch, does this have a chance of making 099?
No longer blocks: 107066
Whiteboard: [correctness] PDT- → [correctness]
Blocks: 107066
No longer blocks: 107066
I'm afraid this patch doesn't account for the platform specific stuff we still
need to do. I created this thinking we could use <F1> all the way around. Need
to make another one.
Filed bug 124393 VK_HELP. Feel free to fix the title etc.

Ian: i'd suggest you write a fix that relies on VK_HELP, ignore the other possibilities.
Depends on: 124393
Comment on attachment 41079 [details] [diff] [review]
A real patch for adding F1 to addrbook, editor, nav, mailnews

marking patch so casual readers of this bug are aware that this patch isn't the
final patch

The problem is that this should be platform-specific:

+  <key id="key_help"	keycode="VK_F1"      command="cmd_help"  />
Attachment #41079 - Flags: needs-work+
OK, I'll go to town on a new patch and assume that 124393 will be fixed, since
that is the best way to make this work on different platforms, but the
dependency is a real one.
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to adt@netscape.com.  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
the blocker is nearly fixed...
Keywords: nsbeta1
Target Milestone: mozilla1.2 → mozilla1.0
Blocks: 67376
Ian, I fixed this while doing the menu restructuring, however I just noticed two
problems:

1. It's only fixed in commercial.
2. It hardcodes VK_F1; I see now it should be VK_HELP.

I think we should just go ahead and try to change it to VK_HELP for machv.  The
code is at
http://lxr/commercial/source/xpfe/communicator/resources/content/communicatorOverlay.xul#99
argh! who reviewed that?? That's not in a platform-specific file!
please take it out asap!
I thought VK_HELP was supposed to do the right thing?
I think brade is reacting to the VK_F1 stuff, not the change you suggest, blake.
Can we go ahead and make a patch for this?
That's what I'm asking... will VK_HELP do the right thing on each platform, 
i.e., can I just make a patch of VK_F1 -> VK_HELP?  Or are platform-specific 
files needed?
Using this query:
http://lxr.mozilla.org/seamonkey/search?string=VK_HELP

it appears that only Mac builds are able to send VK_HELP key codes.

There probably should be a bug for each platform to handle this (Solaris (bug
48322 or bug 13168?), Windows, Linux, etc.).  Some platforms may already have that.

Long ago, I would have guessed that this bug was intended to do the
platform-specific work for Windows since F1 is a windows-specific keybinding.

At this point, I think the easiest thing is probably to do the platform-specific
overlays (unless you are comfortable working in the Windows key event code).
I did not know this before:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnacc/html/ATG_KeyboardShortcuts.asp

Says that F1 should bring application help.
and that shift+F1 should bring up contextual help.
Changing summary, to reflect OS standards. Sorry I didn't have this correct before.
Summary: F1 key doesn't bring up contextual help → Shift+F1 on Win/*nix, Cmd+? on Mac key doesn't bring up contextual help
You just changed the meaning of this bug for Windows.  Shift+F1 on Windows
should display a tooltip for help.  It's like using the question mark in a
dialog and clicking an object.  F1 should still display context-sensitive help,
being the help window opened to a topic related to the window and/or function
you're using.

I would think this would be similar on *nix, too.

Please change the summary back to the original, "F1 key doesn't bring up
contextual help".
Alright, changing back as Dean says.
I'm a bit confused by the descriptions of what the keys should do on the MS page.
Summary: Shift+F1 on Win/*nix, Cmd+? on Mac key doesn't bring up contextual help → F1 on Win/*nix, Cmd+? on Mac key doesn't bring up contextual help
Shift+F1 displays a little tooltip.  Right-click on your desktop, select
Properties, then press Shift+F1.
-->blake
Blake, I think you just did some work on this?
Assignee: oeschger → blaker
Status: ASSIGNED → NEW
*** Bug 145846 has been marked as a duplicate of this bug. ***
nsbeta1- per nav triage team
Keywords: nsbeta1nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2alpha
*** Bug 150393 has been marked as a duplicate of this bug. ***
*** Bug 159966 has been marked as a duplicate of this bug. ***
Moving to default owners.
Assignee: blake → rlk
QA Contact: tpreston → stolenclover
Target Milestone: mozilla1.2alpha → ---
Ping...

We are at 1.7b now. Will this ever be solved ?
Seems to work partially; with the patch F1 brings up help from Navigator and
Composer windows, but not from for instance the Bookmark Manager or the
Preferences dialog.

Mac needs an overlay to use Cmd+? instead of F1 however, and to show the
accelerator in the menu. Haven't tested on other platforms.
> +  <key id="key_help"   keycode="VK_F1"      command="cmd_help"  />

You should use VK_HELP instead of VK_F1 for the help key.

Thanks for this patch! I'll compile this into a build and see if I can't get it
to work in Bookmark Manager (and other places, probably).
> You should use VK_HELP instead of VK_F1 for the help key.

VK_HELP is *completely* dysfunctional (on non-Mac platforms, from what I can
gather).  See <http://lxr.mozilla.org/mozilla/search?string=VK_HELP>.  See also
the attached testcase; VK_HELP will not work while VK_F2 will, even though the
implementation syntaxes are exactly the same.  (Sorry for the unusual size of
the XUL window; my grasp of XUL is somewhat minimal.)

I don't know what needs to be done to hook up VK_HELP for real on all platforms
(if it is indeed hooked up on the Mac).  In the interim I say go for a
preprocessor #ifdef by platform.

(R.J., note that this also applies to the equivalent Firefox Help bug:
<http://bugzilla.mozdev.org/show_bug.cgi?id=5409>.  With 0.9/1.0 coming I say
use the hack, because there's no way VK_HELP will be fixed on the branch.)
(In reply to comment #70)
> I don't know what needs to be done to hook up VK_HELP for real on all platforms
> (if it is indeed hooked up on the Mac).  In the interim I say go for a
> preprocessor #ifdef by platform.

VK_HELP does not seem to be hooked up properly on the Mac: the test case does 
not trigger when I push Help. (Seamonkey build 2004052708, Mac OS X 10.3.4.)

Note that the "Help" key on the Mac doesn't actually bring up help in any application anyway, so far as I 
can tell. (In some apps it turns the cursor into a question mark, then beeps at you when you click 
something, but never produces any help.) Laptop keyboards don't even have the key... the proper 
access key for help in Mac OS X is Command+? (Command+Shift+/).
I hope this bug is fixed soon. F1 has been a windows standard since...forever 
Can someone tell me the Help key on the Mac? We need to get this wrapped up.
Firefox Help has had this for awhile.
Status: NEW → ASSIGNED
Keywords: nsbeta1-, pp
Whiteboard: [correctness]
(In reply to comment #73)
> Firefox Help has had this for awhile.

Not if you're on a mac...
(In reply to comment #74)
> (In reply to comment #73)
> > Firefox Help has had this for awhile.
> 
> Not if you're on a mac...

yup, that's why I want to know the mac keyboard shortcut for Help :).
> Note that the "Help" key on the Mac doesn't actually bring up help in any
application anyway, so far as I 
> can tell. (In some apps it turns the cursor into a question mark, then beeps
at you when you click 
> something, but never produces any help.) Laptop keyboards don't even have the
key... the proper 
> access key for help in Mac OS X is Command+? (Command+Shift+/).

Brion, in the applications I have tried Command+? (on my keyboard
Command+Shift++) the app help loads in the OS X Help Viewer. On the contrary,
Fetch and IE 5.2 loads its own help viewer when pressing the Help key. So, I
wonder if the Help key isn't a better alternative?

On the other hand, looking at
http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/
Apple says: "the Help key (or Command-? or Command-/) invokes the application’s
help in Help Viewer".

Attached patch Patch (obsolete) — Splinter Review
My computer is a bit messed up, so I don't have a build system to test this
patch on.
Attachment #40969 - Attachment is obsolete: true
Attachment #41061 - Attachment is obsolete: true
Attachment #41078 - Attachment is obsolete: true
Attachment #41079 - Attachment is obsolete: true
Attachment #147786 - Attachment is obsolete: true
(In reply to comment #76)
> Brion, in the applications I have tried Command+? (on my keyboard
> Command+Shift++) the app help loads in the OS X Help Viewer. On the contrary,
> Fetch and IE 5.2 loads its own help viewer when pressing the Help key. So, I
> wonder if the Help key isn't a better alternative?

Those are both very old applications, designed for the old Mac OS. IE hasn't been updated since 2001, 
when OS X was young. The only apps I regularly use that respond to the Help key are iTunes and 
FileMaker, and both also respond to command+? and list it as the shortcut key in the Help menu. Both 
also ran on the old Mac OS in the olden days, if I'm not mistaken.

Further, my PowerBook's built-in keyboard doesn't even *have* a help key.

If you want it to launch help in response to _both_ "Help" and command+?, that would probably be fine, 
but if you have to choose one it really needs to be command+?. Not doing so would be like declaring 
that "SysRq" will bring up Help on Windows because you're ReQuesting help from the SYStem. :)
Attachment #154576 - Flags: review?(neil.parkwaycc.co.uk)
(In reply to comment #78)
> My computer is a bit messed up, so I don't have a build system to test this
> patch on.

Doesn't seem to do anything on Mac OS X.
Comment on attachment 154576 [details] [diff] [review]
Patch

keycode="?" is wrong; you probably need key="?" modifiers="accel" - also,
unless it would really hurt something, you might as well define both keys - and
can you put the keys in the existing keyset please?
Attachment #154576 - Flags: review?(neil.parkwaycc.co.uk) → review-
Comment on attachment 154576 [details] [diff] [review]
Patch

Oh wait, helpMenuOverlay... well, navKeys is still wrong, your irc suggestion
of tasksKeys might work or you could try just <keyset>
Comment on attachment 154576 [details] [diff] [review]
Patch

Ah, having platform keys would be nice if the menu displayed the correct key.
summary implies this is not a Win98/PC only bug
OS: Windows 98 → All
Hardware: PC → All
I made a testcase for VK_HELP:
http://bugzilla.mozilla.org/attachment.cgi?id=154806&action=view
You want "tasksKeys" indeed.

VK_HELP had the nasty side-effect of being triggered by almost any key. That's
bug 252750, which is already fixed on trunk. 

Also note that Cmd+? doesn't work, see bug 253680 comment 0.
--> default owners
Assignee: rlk → neil.parkwaycc.co.uk
Status: ASSIGNED → NEW
Product: Browser → Seamonkey
Adjusting summary (we shouldn't bring up context help with those keys) and
taking bug. I'll give this a try once I've fixed bug 127704.
Assignee: neil.parkwaycc.co.uk → stefan_h
Summary: F1 on Win/*nix, Cmd+? on Mac key doesn't bring up contextual help → F1 on Win/*nix, Cmd+? on Mac key doesn't bring up help
Target Milestone: --- → Seamonkey1.0alpha
I'll start working on this next week.
Status: NEW → ASSIGNED
Enable F1 on win/nix and Help/Cmd+? on mac. Only tested on mac... Part of the
patch based on Firefox code. The Cmd+? will not work properly on certain
locales (because of bug 280805 and/or the way the "native" mac menus work).
However, I do think it is worth implementing anyway. It's the standard-shortcut
for opening Help on mac. Also, there's the possibility of disabling the
shortcut.
Attachment #154576 - Attachment is obsolete: true
Attachment #186109 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #186109 - Flags: review?(kairo)
Comment on attachment 186109 [details] [diff] [review]
Make F1 on win/nix and Help/Cmd+? on mac open Help

this basically looks good to me, but as I feared I can't completely r+ this as
I don't know the <key> stuff well enough so that I can tell if it's fully
correct. I guess Neil can probably r+sr this though (once he's back).
Comment on attachment 186109 [details] [diff] [review]
Make F1 on win/nix and Help/Cmd+? on mac open Help

For '<key id="key_openHelpFrontend"', I don't see a command.  Is that
intentional?

What platforms/recent builds has this been tested on?
(In reply to comment #91)
> (From update of attachment 186109 [details] [diff] [review] [edit])
> For '<key id="key_openHelpFrontend"', I don't see a command.  Is that
> intentional?

Yes, that's intentional. key_openHelpFrontend is for the mac menu (Cmd+?). The
mapping is done different, so you need one command-less <key.../> for the menu
and one <key...> for the mapping of the command.

Shift+/ == ? on en-US keyboards. But pressing Cmd+Shift+/ will generate an
unshifted charcode (bug 280805), thus you need to map the openHelp() command to
Cmd+Shift+/ (the idea is taken from toolkit's baseMenuOverlay.xul).
> 
> What platforms/recent builds has this been tested on?

Only on mac (comment #89). It built and worked fine (en-US kb layout) ;)
Comment on attachment 186109 [details] [diff] [review]
Make F1 on win/nix and Help/Cmd+? on mac open Help

Thanks for the explanation; I missed it in the diff.
r=brade
Attachment #186109 - Flags: review?(kairo) → review+
Comment on attachment 186109 [details] [diff] [review]
Make F1 on win/nix and Help/Cmd+? on mac open Help

Neil suggested (via e-mail) a better way of doing this.  New patch is coming
soon...
Attachment #186109 - Attachment is obsolete: true
Attachment #186109 - Flags: superreview?(neil.parkwaycc.co.uk)
Attached patch New version, no ifdefs (obsolete) — Splinter Review
Here's a new version, following Neils suggestions (using overlays instead of
ifdefs). Also adding the Window menu to the View Source/View partial Source
window(s). Only tested on mac.

Brade, since you were so kind to volunteer last time, can you review this one
as well?
Attachment #187405 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #187405 - Flags: review?(brade)
Comment on attachment 187405 [details] [diff] [review]
New version, no ifdefs

r=brade
Attachment #187405 - Flags: review?(brade) → review+
Comment on attachment 187405 [details] [diff] [review]
New version, no ifdefs

>+      <menu id="windowMenu"/>
>+
It occurs to me that most windows e.g. ChatZilla, DOM Inspector actually
include both the tasks and window menus, so I guess it would be more consistent
if you could do that here too.

>+    <key id="key_openHelp"
>+         key="&openHelpFrontend.key;"
>+         modifiers="&openHelpFrontend.modifiers;"/>
>+    <key key="&openHelpCmd.key;"
>+         modifiers="&openHelpCmd.modifiers;"
>+         command="cmd_openHelp"/>
>+    <key keycode="&openHelp2Cmd.key;"
>+         command="cmd_openHelp"/>
You might want to consider commenting on these a little. The .dtd's comment
isn't too great either.

>+  <!-- Tasks Keys -->
>+  <keyset id="tasksKeys">
>+    <key id="key_openHelp"
>+         keycode="&openHelpCmd.key;"/>
>+  </keyset>
You missed the command="cmd_openHelp" on this one. sr=me with this fixed.
Attachment #187405 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
Changed comments in the .dtd file, added comments in
mac/platformCommunicatorOverlay.xul and fixed the missing cmd_openHelp.
Carrying over review flags.

Requesting approval 1.8b3 for a SeaMonkey-only change. This will fix a
long-time missing feature: keyboard access to the Help Viewer.
Attachment #187405 - Attachment is obsolete: true
Attachment #187556 - Flags: superreview+
Attachment #187556 - Flags: review+
Attachment #187556 - Flags: approval1.8b3?
Comment on attachment 187556 [details] [diff] [review]
Final version, carrying over flags (Checked in)

Has this been tested to make sure it does not break Thunderbird?
Comment on attachment 187556 [details] [diff] [review]
Final version, carrying over flags (Checked in)

(In reply to comment #99)
> (From update of attachment 187556 [details] [diff] [review] [edit])
> Has this been tested to make sure it does not break Thunderbird?
> 

The critical file seems to be platformCommunicatorOverlay.xul, running
Thunderbird with its platforCommunicatorOverlay patched works fine. It looks
like it isn't used at all, there is no corresponding .dtd file in Thunderbirds
en-US.jar
Attachment #187556 - Flags: approval1.8b3? → approval1.8b3+
Comment on attachment 187556 [details] [diff] [review]
Final version, carrying over flags (Checked in)

Checking in extensions/help/resources/content/helpMenuOverlay.xul;
new revision: 1.14; previous revision: 1.13
extensions/help/resources/locale/en-US/shortcuts.xhtml;
new revision: 1.17; previous revision: 1.16
xpfe/browser/resources/content/viewSourceOverlay.xul;
new revision: 1.25; previous revision: 1.24
xpfe/communicator/resources/content/mac/platformCommunicatorOverlay.xul;
new revision: 1.13; previous revision: 1.12
xpfe/communicator/resources/content/unix/platformCommunicatorOverlay.xul;
new revision: 1.6; previous revision: 1.5
xpfe/communicator/resources/content/win/platformCommunicatorOverlay.xul;
new revision: 1.6; previous revision: 1.5
xpfe/communicator/resources/locale/en-US/mac/platformCommunicatorOverlay.dtd;
new revision: 1.7; previous revision: 1.6
xpfe/communicator/resources/locale/en-US/unix/platformCommunicatorOverlay.dtd;
new revision: 1.5; previous revision: 1.4
xpfe/communicator/resources/locale/en-US/win/platformCommunicatorOverlay.dtd;
new revision: 1.5; previous revision: 1.4
done
Attachment #187556 - Attachment description: Final version, carrying over flags → Final version, carrying over flags (Checked in)
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.