5.96 KB, patch
|Details | Diff | Splinter Review|
1.44 KB, patch
|Details | Diff | Splinter Review|
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
note the above is win v.s. mac diff.
asa doesn't want to own this bug.
Assignee: asa → tao
Component: Browser-General → Tracking
QA Contact: doronr → chofmann
The module owner should own this bug -> arronl. Please pass it to blake and then rods. thx!
Assignee: tao → aaronl
Component: Tracking → Browser-General
Please fix this by moz0.9.4 please!
Target Milestone: --- → mozilla0.9.4
What is the process required to get accessible.properties in all the correct places?
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"
My bug is spun off to bug 96473 -> blake
Assignee: aaronl → blakeross
Priority: -- → P2
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Hi, Blake: Any chance we fix this in 0.9.4 branch?
aaron, why do I own this?
Assignee: blakeross → aaronl
My part of this is done. Tao, you can bounce it to whoever you wish to next.
Assignee: aaronl → tao
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
reassign to new owner ->dbragg
Assignee: tao → dbragg
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.
Don, I just tested these changes on my build with the accessible tools. Everything looks fine.
Thanks John. Onward to get the appropriate reviews!
Looks like things radically changed for the gfx part of the fix. (the print dialog). Posting new diff.
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.
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.
sr=alecf on both of these patches, whichever need to go in
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+
Comment on attachment 62132 [details] [diff] [review] Diff of changes to accessible, gfx and xpfe/components reflect sr=alecf
Attachment #62132 - Flags: superreview+
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.