Closed Bug 363054 Opened 15 years ago Closed 15 years ago
Ctrl-Shift Keyboard Shortcuts (multiple modifier keys) broken (linux)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20061205 SeaMonkey/1.1 Mnenhy/0.7.4.10004 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/20061205 SeaMonkey/1.1 Mnenhy/0.7.4.10004 In recent Seamonkey 1.1 builds the ctrl-shift-M Keyboard Shortcut isn't interpreted correctly, instead of mark folder read it acts exactly like ctrl-m without shift-key and starts a new message. Reproducible: Always Steps to Reproduce: 1.Press Ctrl-Shift-m on a folder in MailNews 2. 3. Actual Results: New message is started Expected Results: All Messages in the Folder should be marked as read. For Linux this Shortcut was changed from ctrl-Shift-c some time ago due to <https://bugzilla.mozilla.org/show_bug.cgi?id=186789> I'm lacking the intermediate builds and can only tell that it still worked with <Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52pre) Gecko/20061126> SeaMonkey/1.1b> and ceased to do so with <Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20061205 SeaMonkey/1.1>
This is not only an issue with this single Shortcut. Ctrl-Shift-I (Dom-Inspector) is broken as well. Similar problem, Ctrl-Shift-I opens page info, just like Ctrl-I does.
Component: MailNews: Main Mail Window → XP Apps: GUI Features
Summary: Ctrl-Shift-M for mark folder read on Linux doesn't work → Ctrl-Shift Keyboard Shortcuts broken
Version: unspecified → 1.8 Branch
Regression from bug 351310? Does this affect the latest Firefox 220.127.116.11 nightlies as well?
Yes, I'm afraid this is broken on Linux, mea culpa. Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:18.104.22.168) Gecko/20061206 BonEcho/22.214.171.124 SeaMonkey trunk on Linux does not seem to be affected though. How about Firefox 126.96.36.199 on Windows?
Assignee: mail → mats.palmgren
Severity: normal → major
Assignee: mats.palmgren → nobody
Status: UNCONFIRMED → NEW
Component: XP Apps: GUI Features → Keyboard: Navigation
Ever confirmed: true
Product: Mozilla Application Suite → Core
QA Contact: keyboard.navigation
A quick fix to make this work again. We can figure out something later that takes into account non-default key/mask settings in prefs.js if we need to...
Have you considered excluding 'A' to 'Z' from being unshifted instead? Seems that opposite to Windows, the DOM-keyCode's being uppercase is relevant at a later point. That would be the less hacky solution... (In reply to comment #3) > How about Firefox 188.8.131.52 on Windows? Works as expected: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206pre) Gecko/2006120403 BonEcho/220.127.116.11pre
It works fine on trunk, even though the widget code is exactly the same: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/widget/src/gtk2/nsWindow.cpp&rev=1.193&root=/cvsroot&mark=2105-2140#2099 http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/widget/src/gtk2/nsWindow.cpp&rev=MOZILLA_1_8_BRANCH&root=/cvsroot&mark=1845-1880#1839 so there must be some difference in how keyboard shortcuts are processed elsewhere...
(In reply to comment #5) > Have you considered excluding 'A' to 'Z' from being unshifted instead? Seems > that opposite to Windows, the DOM-keyCode's being uppercase is relevant at a > later point. That would be the less hacky solution... It's rather late in the game, I prefer the "don't do this at all if Control is pressed"-solution for now.
Comment on attachment 247849 [details] [diff] [review] Patch rev. 1 (In reply to comment #7) In that case, fine by me.
Attachment #247849 - Flags: review?(zeniko) → review+
We already have builds in testing for 18.104.22.168 on a tight schedule, we'll have to relnote this. In the unlikely event a critical bug forces a respin we can consider taking this as a ride-along.
Attachment #247849 - Flags: superreview?(pavlov) → superreview+
Comment on attachment 247849 [details] [diff] [review] Patch rev. 1 a=schrep for 22.214.171.124/126.96.36.199 based on convos on IRC
Comment on attachment 247849 [details] [diff] [review] Patch rev. 1 This patch doesn't apply on 188.8.131.52. Is the fix needed there?
dveditz says this is 1.8.1 only. Leaving open for trunk landed in case that's needed.
Landed on trunk to keep the code in sync with 1.8 branch. The bug did not occur on trunk but since we don't know why it didn't, it seems safer to have the patch there too, until we know for sure... -> FIXED
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
*** Bug 363131 has been marked as a duplicate of this bug. ***
verified fixed for 184.108.40.206 on Fedora FC 6 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/20061208 Firefox/18.104.22.168
*** Bug 364206 has been marked as a duplicate of this bug. ***
Summary: Ctrl-Shift Keyboard Shortcuts broken (linux) → Ctrl-Shift Keyboard Shortcuts (multiple modifier keys) broken (linux)
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.