Build errors being fixed here:
layout/xul/nsDeckFrame.cpp:164:43: error: unknown type name 'nsSetAttrRunnable'
layout/xul/nsMenuBarListener.cpp:45:7: error: cannot initialize a member subobject of type 'mozilla::dom::EventTarget *' with an rvalue of type 'nsINode::Document *' (aka 'mozilla::dom::Document *')
(...where "Document" is not defined; this patch includes the header that defines it, which fixes this.)
layout/xul/nsBoxFrame.cpp:270:10: error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
dist/include/nsIRollupListener.h:36:38: error: no type named 'LayoutDeviceIntPoint' in namespace 'mozilla'
(For this error, this patch is changing a header outside of layout/xul, but
it's still required in order for layout/xul to build properly, since it's
#included by layout/xul/nsXULPopupManager.cpp (indirectly, via its .h file).
Differential Revision: https://phabricator.services.mozilla.com/D138092
Build errors being fixed here:
layout/xul/nsDeckFrame.cpp:164:43: error: unknown type name 'nsSetAttrRunnable'
layout/xul/nsMenuBarListener.cpp:45:7: error: cannot initialize a member subobject of type 'mozilla::dom::EventTarget *' with an rvalue of type 'nsINode::Document *' (aka 'mozilla::dom::Document *')
(...where "Document" is not defined; this patch includes the header that defines it, which fixes this.)
dist/include/nsIRollupListener.h:36:38: error: no type named 'LayoutDeviceIntPoint' in namespace 'mozilla'
(For this error, this patch is changing a header outside of layout/xul, but
it's still required in order for layout/xul to build properly, since it's
#included by layout/xul/nsXULPopupManager.cpp (indirectly, via its .h file).
Differential Revision: https://phabricator.services.mozilla.com/D138092
`keyup` event of `Alt` key should be fired in content process even if it'll
activate the menubar, and it should be cancelable as same as before enabling
e10s.
Unfortunately, the new test is complicated even they test simple things.
The reason is, this test requires the window running it is the active window.
However, the window may become inactive on Linux, therefore, this test
needs to manage window state by itself.
And another reason is, after inactivating the menubar, somebody keeps
consuming keyboard events in chrome. Although, popups shouldn't be
opened by this test, but waiting all popups hidden makes the remaining
intermittent failure gone. Therefore, this patch waits all popups become
hidden after inactivating the menubar and before new test.
Differential Revision: https://phabricator.services.mozilla.com/D95984
`keyup` event of `Alt` key should be fired in content process even if it'll
activate the menubar, and it should be cancelable as same as before enabling
e10s.
Unfortunately, the new test is complicated even they test simple things.
The reason is, this test requires the window running it is the active window.
However, the window may become inactive on Linux, therefore, this test
needs to manage window state by itself.
And another reason is, after inactivating the menubar, somebody keeps
consuming keyboard events in chrome. Although, popups shouldn't be
opened by this test, but waiting all popups hidden makes the remaining
intermittent failure gone. Therefore, this patch waits all popups become
hidden after inactivating the menubar and before new test.
Differential Revision: https://phabricator.services.mozilla.com/D95984
Converts `ui.key.menuAccessKeyFocuses` to a static pref and removes `nsMenuBarListener::InitializeStatics()`. This pref sets to `true` in windows and linux, which may affect behavior in SeaMonkey and Thunderbird.
Differential Revision: https://phabricator.services.mozilla.com/D69617
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
This is consistent with other apps and toolkits (GTK, LibreOffice), and
gives blind people a better experience by providing a consistent
desktop experience, and consistent behavior of the right arrow key
regardless of the first focusable element.
---
layout/xul/nsMenuBarListener.cpp | 2 +-
layout/xul/nsXULPopupManager.cpp | 17 ++++++++++++++++-
toolkit/content/tests/widgets/window_menubar.xul | 14 ++++++++------
3 files changed, 25 insertions(+), 8 deletions(-)
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
Currently, nsMenuBarListener::KeyPress() handles F10 key before remote content handles it. However, if a remote process has focus, the keyboard event should be handled in the content first. Then, only when it's not consumed in the remote process, menubar should handle the F10 key press.
MozReview-Commit-ID: GDf4POAPsTy
--HG--
extra : rebase_source : a450755d89bc410d17fef55fad98533169e2eff5
Currently, nsMenuBarListener::KeyPress() handles F10 key before remote content handles it. However, if a remote process has focus, the keyboard event should be handled in the content first. Then, only when it's not consumed in the remote process, menubar should handle the F10 key press.
MozReview-Commit-ID: GDf4POAPsTy
--HG--
extra : rebase_source : e016bc6dd7b5499458b6abc365f4879c1639f841
nsMenuBarListener::KeyPress() is eKeyEvent listener in the system event group. If the target is a remote process, it shouldn't handle accesskey immediately because preceding eKeyDown event may be consumed in the remote process or eKeyPress event itself may be consumed in the remote process.
This patch makes nsMenuBarListener::KeyPress() mark eKeyPress event as "waiting reply from remote process" only when the event matches with a menu item's accesskey and it will be send to a remote process later. Then, reply event should be handled in this method if it's available.
MozReview-Commit-ID: KOpCVgElnca
--HG--
extra : rebase_source : 881ec01f5c8e21c790bf9a8c3167d6c3f932524a
Currently, access key is handled in EventStateManager::PreHandleEvent() with eKeyPress event, i.e., before dispatching it into the DOM tree, if the access key is registered in EventStateManager. So, the main process does not check if the preceding eKeyDown event is consumed in focused remote process.
When preceding eKeyDown event is consumed in the main process, eKeyPress event won't be dispatched by widget. However, if remote process has focus, it's impossible widget to stop dispatching eKeyPress event because preceding eKeyDown event hasn't been handled in the focused remote process yet. Therefore, main process needs to post eKeyPress event to check if preceding eKeyDown event was consumed. When eKeyPress event is marked as "waiting reply from remote process", TabChild sends it back to the main process only when preceding eKeyDown event wasn't consumed. So, only when eKeyPress event is back to the main process, main process should handle accesskey with it.
This patch makes EventStateManager::PreHandleEvent() check if a remote target has focus before handling accesskey. If a remote process has accesskey and there is an accesskey matching with eKeyPress event, it marks the event as "waiting reply from remote content" and stop propagation in the process.
Finally, when eKeyPress event is sent back to TabParent, TabParent::RecvReplyKeyEvent() calls EventStateManager::HandleAccessKey() before dispatching the reply event into the DOM tree.
MozReview-Commit-ID: KsOkakaIVzb
--HG--
extra : rebase_source : 7e0c6966a1bde085e34d45bca4b0166b9fc2f3f1
This patch makes nsMenuBarListener clear its accesskey state when it receives a "deactivate" event of its top level window and reverts the change of nsMenuBarListener::Blur() by bug 625151.
"blur" event may be caused by focus move in the contents after "mosuedown" event. Therefore, mAccessKeyDownCanceled may be cleared unexpectedly. Listening to "deactive" event keeps bug 625151's fix because it's a bug after deactivating the window with Alt+Tab.
MozReview-Commit-ID: 4mAmXpxmDdv
--HG--
extra : rebase_source : 1bd9299a37bc5a1feccb61ba6c3db6b389560ec0
Let's move the code adding/removing event listers to nsMenuBarListener because it makes what we maintain them easier.
This patch makes nsMenuBarListener store event target which is composed document node of the menubar content as a weak reference but this must be safe because when nsMenuBarFrame (stored as mMenuBarFrame) is being destroyed, OnDestroyMenuBarFrame() which clears the storing event target reference is always called. We should be able to assume that the content and its composed document has never gone before destroying its frame...
MozReview-Commit-ID: DdOtRzUAL1Z
--HG--
extra : rebase_source : bfc337aaad447ad4a9d78b2f3a9e49c72db1498e
All the event interfaces changed except for nsIDOMUIEvent and its inheritors.
--HG--
extra : transplant_source : %A5U%3F%80%2B%DD%01%F4%D8%21%F2%E9z%C1%D6%AA%CC%D4%EC%F8