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

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[Kathleen :Brade]

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!

Comment 1

[Henri Sivonen (:hsivonen)]

Those shortcuts are indeed i18n-unfriendly (see bug 36048).

Comment 2

[rubydoo123]

setting to nsbeta3+, Akkana can you please set the priority for this one -- 
thanks

Comment 3

[Akkana Peck]

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.

Comment 4

[Kathleen :Brade]

yes, linux only bug (filed the bug on Mac since I was experimenting on my Linux 
box); sorry for the confusion

Comment 5

[Akkana Peck]

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.

Comment 6

[Akkana Peck]

Filed bug 49770 on the bigger and smaller issue.

Comment 7

[sujay]

verified in 8/31 build.