If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

alt-shift-[ and alt-shift-] (Composer) don't work on Linux

VERIFIED FIXED in M18

Status

()

Core
Editor
P3
normal
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: Kathleen Brade, Assigned: Akkana Peck)

Tracking

({pp})

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+])

(Reporter)

Description

17 years ago
I noticed that there must be another bug lurking in the gtk key handling code.  
Unfortunately I'm leaving for sabbatical tomorrow so I won't have time to fix it.  
Assigning to Akkana for now; feel free to redistribute as necessary.

With a debug linux build from today (trunk), in Composer, I selected some text 
and pressed alt-shift-[ and alt-shift-] (Smaller and Larger).  Neither of these 
has any effect.  I'm guessing that the [ is actually sending a { which is 
confusing the xul.  There are several ways this bug could be fixed (change the 
keybinding or change the widget code).  I leave that up to Akkana for now.

By the way, today's Mac debug build, this keybinding does work so I'm guessing 
that the "correct" fix is in the widget code but if we need to fix it to ship, 
adding a separate keybinding for alt-shift-{ may be acceptable.

One last comment, I think that this keybinding may be one that I18n is concerned 
about localizing (different keyboards have different layouts and the keybindings 
don't always make sense on other keyboards).  Not sure what that bug # is; sorry!
Those shortcuts are indeed i18n-unfriendly (see bug 36048).
Blocks: 36048

Comment 2

17 years ago
setting to nsbeta3+, Akkana can you please set the priority for this one -- 
thanks
Keywords: correctness, nsbeta3
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
(Assignee)

Comment 3

17 years ago
It's probably just a couple more characters that need to be added to the
arbitrary non-I18nable list in nsGtkEventHandler.cpp.  I'll take a look.

This is a Unix-only bug, despite the fact that it was marked Mac, right?
Changing platform, please correct me if that's inappropriate.
Status: NEW → ASSIGNED
OS: Mac System 8.5 → Linux
Hardware: Macintosh → PC
(Reporter)

Comment 4

17 years ago
yes, linux only bug (filed the bug on Mac since I was experimenting on my Linux 
box); sorry for the confusion
Keywords: 4xp, pp
(Assignee)

Comment 5

17 years ago
These are working now.  Perhaps it was fixed by my changes to the xulkey
handling stuff.

That is to say, they work as well as the "bigger" and "smaller" buttons, which
is to say, not very well.  The first time I click smaller, the text gets
smaller, but subsequent clicks do nothing.  The first and third clicks on bigger
have an effect, but no subsequent ones.  I'll file a separate bug on that issue.
(Assignee)

Comment 6

17 years ago
Filed bug 49770 on the bigger and smaller issue.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 7

17 years ago
verified in 8/31 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.