Platform files should go to "en-win.jar"

VERIFIED FIXED in mozilla0.9.9

Status

SeaMonkey
General
P2
normal
VERIFIED FIXED
17 years ago
13 years ago

People

(Reporter: tao, Assigned: dbragg)

Tracking

Trunk
mozilla0.9.9
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: ETA: 12/10/01)

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
Only in win/bin/chrome/locale/en-US/communicator: gfx
Only in win/bin/chrome/locale/en-US/global: accessible.properties
Only in win/bin/chrome/locale/en-US/global: nsWindowsHooks.properties
(Reporter)

Comment 1

17 years ago
note the above is win v.s. mac diff.
(Reporter)

Updated

17 years ago
Blocks: 62177

Comment 2

17 years ago
asa doesn't want to own this bug.
Assignee: asa → tao
Component: Browser-General → Tracking
QA Contact: doronr → chofmann
(Reporter)

Comment 3

17 years ago
The module owner should own this bug -> arronl. Please pass it to blake and
then rods. thx!
Assignee: tao → aaronl
Component: Tracking → Browser-General
(Reporter)

Comment 4

17 years ago
Please fix this by moz0.9.4 please!
Target Milestone: --- → mozilla0.9.4

Comment 5

17 years ago
What is the process required to get accessible.properties in all the correct places?
(Reporter)

Comment 6

17 years ago
Currently, they are in en-US.jar. You'd need to move them to en-win.jar and
then change the chrome url references accordingly.

For example,
> Only in win/bin/chrome/locale/en-US/communicator: gfx
Move this from "jar:resource:/chrome/en-US.jar!/locale/communicator/gfx" to
"jar:resource:/chrome/en-win.jar!/locale/communicator-platform/gfx"

> Only in win/bin/chrome/locale/en-US/global: accessible.properties
> Only in win/bin/chrome/locale/en-US/global: nsWindowsHooks.properties
Move these from "jar:resource:/chrome/en-US.jar!/locale/global" to
"jar:resource:/chrome/en-win.jar!/locale/global-platform"



Comment 7

17 years ago
My bug is spun off to bug 96473

-> blake
Assignee: aaronl → blakeross
Priority: -- → P2
Target Milestone: mozilla0.9.4 → mozilla0.9.5
(Reporter)

Comment 8

17 years ago
Hi, Blake:


Any chance we fix this in 0.9.4 branch?

Comment 9

17 years ago
aaron, why do I own this?
Assignee: blakeross → aaronl

Comment 10

17 years ago
My part of this is done.

Tao, you can bounce it to whoever you wish to next.
Assignee: aaronl → tao
(Reporter)

Comment 11

17 years ago
OK, "chrome/locale/en-US/communicator: gfx" is packaged on both win and unix but
not mac.


Target Milestone: mozilla0.9.5 → mozilla0.9.6
(Reporter)

Comment 12

16 years ago
reassign to new owner ->dbragg
Assignee: tao → dbragg
(Reporter)

Updated

16 years ago
Target Milestone: mozilla0.9.6 → mozilla0.9.7
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Whiteboard: ETA: 12/10/01
(Assignee)

Updated

16 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.8
(Assignee)

Comment 13

16 years ago
Created attachment 62132 [details] [diff] [review]
Diff of changes to accessible, gfx and xpfe/components

Here's the fix for this bug.  I tested the gfx and xpfe\components\windowshooks
changes but was unable to test the accessible changes.

Comment 14

16 years ago
Don, I just tested these changes on my build with the accessible tools.
Everything looks fine.
(Assignee)

Comment 15

16 years ago
Thanks John.  Onward to get the appropriate reviews!
(Assignee)

Comment 16

16 years ago
Looks like things radically changed for the gfx part of the fix.  (the print
dialog).  Posting new diff.
(Assignee)

Comment 17

16 years ago
Created attachment 63426 [details] [diff] [review]
New patch for print dialog part of fix (found in gfx/src/windows)

A lot of code was removed from nsDeviceContextSpecFactoryW.cpp including the
chrome url used for the printdialog.properties file.  It was moved to
nsDeviceContextSpecWin.cpp.  This patch shows the bug fix applied to that file.
(Reporter)

Updated

16 years ago
Attachment #62132 - Attachment is obsolete: true
(Reporter)

Updated

16 years ago
Attachment #63426 - Flags: review+
(Reporter)

Updated

16 years ago
Attachment #62132 - Attachment is obsolete: false
Attachment #62132 - Attachment is patch: true
Attachment #62132 - Flags: review+
(Reporter)

Comment 18

16 years ago
Hi, John:

Thanks for verifying the patch for us. One question: is the test done on all 
platform? If not, would you let QA know what to look for on Linux & Mac? Such
platform-specific changes sometime affect the platforms we didn't expect.

Comment 19

16 years ago
sr=alecf on both of these patches, whichever need to go in
(Reporter)

Comment 20

16 years ago
Comment on attachment 63426 [details] [diff] [review]
New patch for print dialog part of fix (found in gfx/src/windows)

update for sr=alecf
Attachment #63426 - Flags: superreview+
(Reporter)

Comment 21

16 years ago
Comment on attachment 62132 [details] [diff] [review]
Diff of changes to accessible, gfx and xpfe/components

reflect sr=alecf
Attachment #62132 - Flags: superreview+
(Reporter)

Updated

16 years ago
Keywords: nsbeta1+
Target Milestone: mozilla0.9.8 → mozilla0.9.9
(Assignee)

Comment 22

16 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 23

16 years ago
Mark verified
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.