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

Status: VERIFIED FIXED

(SeaMonkey :: General, defect, P2)

Description

[tao]

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

Comment 1

[tao]

note the above is win v.s. mac diff.

Comment 2

[timeless]

asa doesn't want to own this bug.

Comment 3

[tao]

The module owner should own this bug -> arronl. Please pass it to blake and
then rods. thx!

Comment 4

[tao]

Please fix this by moz0.9.4 please!

Comment 5

[Aaron Leventhal]

What is the process required to get accessible.properties in all the correct places?

Comment 6

[tao]

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

[Aaron Leventhal]

My bug is spun off to bug 96473

-> blake

Comment 8

[tao]

Hi, Blake:


Any chance we fix this in 0.9.4 branch?

Comment 9

[Blake Ross]

aaron, why do I own this?

Comment 10

[Aaron Leventhal]

My part of this is done.

Tao, you can bounce it to whoever you wish to next.

Comment 11

[tao]

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

Comment 12

[tao]

reassign to new owner ->dbragg

Comment 13

[dbragg]

Attachment: 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

[John Gaunt (redfive)]

Don, I just tested these changes on my build with the accessible tools.
Everything looks fine.

Comment 15

[dbragg]

Thanks John.  Onward to get the appropriate reviews!

Comment 16

[dbragg]

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

Comment 17

[dbragg]

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

Comment 18

[tao]

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

[Alec Flett]

sr=alecf on both of these patches, whichever need to go in

Comment 20

[tao]

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

update for sr=alecf

Comment 21

[tao]

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

reflect sr=alecf

Comment 22

[dbragg]

Fix checked in.

Comment 23

[Jimmy Uen]

Mark verified