fd317cbb296af2ea3624622d73d2d14bda385d07: Bug 1318312 part.3 Selection should move focus at every selection change when it's called by JS r?smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Mar 2017 03:15:20 +0900 - rev 494714
Push 48106 by masayuki@d-toybox.com at Tue, 07 Mar 2017 18:16:32 +0000
Bug 1318312 part.3 Selection should move focus at every selection change when it's called by JS r?smaug Selection may be changed by methods of Selection or methods of Range retrieved by Selection.getRangeAt(). Selection::NotifySelectionListeners() is called after every selection change of each of them, so, this method must be a good point to move focus. If new common ancestor of all ranges is editable and in an editing host, we should move focus to it. Otherwise, if an editing host has focus but new common ancestor is not editable, we should move focus from the editing host. For consistency with the other browsers, this patch doesn't move focus to other focusable element. MozReview-Commit-ID: 6sNsuzwqECX
4adfd540b92b9cde4d1362f06d9a91e1c103fd81: Bug 1342464 - Add regression tests for the FX_TAB_SWITCH_SPINNER_TYPE probe. r?Mossop draft
Mike Conley <mconley@mozilla.com> - Mon, 06 Mar 2017 14:10:58 -0500 - rev 494713
Push 48105 by mconley@mozilla.com at Tue, 07 Mar 2017 18:15:17 +0000
Bug 1342464 - Add regression tests for the FX_TAB_SWITCH_SPINNER_TYPE probe. r?Mossop MozReview-Commit-ID: 7w6rT8uT4I3
227b226e2891d08f7cee524ee3b6c3fef60d2003: Bug 1342464 - Collect Telemetry on when a tab switch spinner is shown. r?billm draft
Mike Conley <mconley@mozilla.com> - Sat, 04 Mar 2017 14:19:22 -0500 - rev 494712
Push 48105 by mconley@mozilla.com at Tue, 07 Mar 2017 18:15:17 +0000
Bug 1342464 - Collect Telemetry on when a tab switch spinner is shown. r?billm MozReview-Commit-ID: 1Ss2f9A2JtK
4c2b51aeb7b306ff3eb7621563245b2f9f513af0: Bug 1339861 - Mark Sync clients as stale if not in the FxA device list. r?markh draft
Edouard Oger <eoger@fastmail.com> - Tue, 28 Feb 2017 16:35:01 -0500 - rev 494711
Push 48104 by bmo:eoger@fastmail.com at Tue, 07 Mar 2017 18:07:15 +0000
Bug 1339861 - Mark Sync clients as stale if not in the FxA device list. r?markh MozReview-Commit-ID: 84Tl3QTHInO
b87159dc7f791f829b967d78c4d42a6b7ca42a46: Bug 1318312 part.3 Selection should move focus at every selection change when it's called by JS r?smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Mar 2017 03:01:53 +0900 - rev 494710
Push 48103 by masayuki@d-toybox.com at Tue, 07 Mar 2017 18:03:14 +0000
Bug 1318312 part.3 Selection should move focus at every selection change when it's called by JS r?smaug Selection may be changed by methods of Selection or methods of Range retrieved by Selection.getRangeAt(). Selection::NotifySelectionListeners() is called after every selection change of each of them, so, this method must be a good point to move focus. If new common ancestor of all ranges is editable and in an editing host, we should move focus to it. Otherwise, if an editing host has focus but new common ancestor is not editable, we should move focus from the editing host. For consistency with the other browsers, this patch doesn't move focus to other focusable element. MozReview-Commit-ID: 6sNsuzwqECX
139e04dc4b7e172105b33a3621290a94b60a2679: Bug 1318312 part.2 Mark Selection as "called from JS" when every Selection API which may cause changing selection is called from JS r?smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Mar 2017 00:57:44 +0900 - rev 494709
Push 48103 by masayuki@d-toybox.com at Tue, 07 Mar 2017 18:03:14 +0000
Bug 1318312 part.2 Mark Selection as "called from JS" when every Selection API which may cause changing selection is called from JS r?smaug Selection needs to be able to distinguish if every selection change is caused by JS (via Selection API) or the others. This patch maps some methods of Range and Selection to *JS(). Each of them marks its instance as "used by JS" and calls corresponding method. With this change, Selection::NotifySelectionListeners() can move focus only when it's caused by Selection API. MozReview-Commit-ID: 1GoLHiIJ10Y
5e4ba999d990b460f22a0920a11d72b41a3e1686: Bug 1318312 part.1 Add automated tests for checking focus move at using Selection API r?smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Mar 2017 02:35:59 +0900 - rev 494708
Push 48103 by masayuki@d-toybox.com at Tue, 07 Mar 2017 18:03:14 +0000
Bug 1318312 part.1 Add automated tests for checking focus move at using Selection API r?smaug Adding automated tests as web platform tests (only for mozilla) for focus move at using Selection API. Although, there is no standards of relation between Selection API and focus, we should move focus when Selection API moves selections into only an editing host or outside of focused editing host. Chrome moves focus as this rules, therefore, user can modify contenteditable editor immediately after web app moves selection. Edge does NOT move focus at using Selection API. However, user can modify contenteditable editor similar to Chrome. We can guess that Edge doesn't need to move focus in its design because perhaps, Edge decides if it's editable only with primary selected range. We cannot take the Edge behavior due to our editor design. So, we can take only Chrome's approach for improving the compatibility. MozReview-Commit-ID: JuLiSMgqODm
0772e5bf020b8634ee591be70813f543ee5fd8d6: Bug 1344149 EditorEventListener shouldn't handle odd focus/blur events which may be created in chrome script r?smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Mon, 06 Mar 2017 20:12:05 +0900 - rev 494707
Push 48103 by masayuki@d-toybox.com at Tue, 07 Mar 2017 18:03:14 +0000
Bug 1344149 EditorEventListener shouldn't handle odd focus/blur events which may be created in chrome script r?smaug EditorEventListener listens any trusted focus/blur events which may be synthesized by JS without proper event class. Then, editor will setup selection limitation. This may cause odd behavior. Therefore, EditorEventListener should stop handling focus/blur events which do not come from nsFocusManager. MozReview-Commit-ID: 7SlfIRgArkr
89fc8f24f451735779c336e12834ea96970e3ce9: Bug 1338369 part.2 nsWindow for GTK should consume Shift key state of eContextMenu event if it's caused by Shift+F10 r?smaug, r?karlt draft
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 24 Feb 2017 20:24:28 +0900 - rev 494706
Push 48103 by masayuki@d-toybox.com at Tue, 07 Mar 2017 18:03:14 +0000
Bug 1338369 part.2 nsWindow for GTK should consume Shift key state of eContextMenu event if it's caused by Shift+F10 r?smaug, r?karlt Shift+F10 is also well-known shortcut key on Linux. So, it should behave same as pressing ContextMenu key. So, for allowing web page to prevent its default, nsWindow for GTK needs to consume Shift key state at dispatching eContextMenu key. Additionally, we should allow to open context menu with Shift+ContextMenu because only ContextMenu key press can be prevented its default by web page. Therefore, we should allow users to open context menu even with keyboard even if web content doesn't want it. Note that Ctrl+Shift+F10 or Alt+Shift+F10 should behave same as Shift+ContextMenu key, but we should discuss later. MozReview-Commit-ID: 1mPGKMTsrkv
5da902027c5f940cee49afc2194f280ce961fa4f: Bug 1338369 part.1 nsWindow for Windows should consume Shift key state at dispatching eContextMenu event if it's caused by Shift+F10 r?smaug, r?jimm draft
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 24 Feb 2017 20:07:52 +0900 - rev 494705
Push 48103 by masayuki@d-toybox.com at Tue, 07 Mar 2017 18:03:14 +0000
Bug 1338369 part.1 nsWindow for Windows should consume Shift key state at dispatching eContextMenu event if it's caused by Shift+F10 r?smaug, r?jimm In PresShell, eContextMenu event is marked as dispatched only in chrome when its shiftKey state is true. However, Shift+F10 causes the context menu, it should not be marked as so because this is standard shortcut key to open context menu on Windows. This patch consumes Shift key state if previous key message is WM_SYSKEYDOWN of F10 before dispatching eContextMenu event. So, user cannot block to prevent its default at opening context menu with Shift+F10, we should discuss this later. MozReview-Commit-ID: 1P9LpeJoQof
87ed13dd2e7809474ed9d9c026f061fcd58e599f: Bug 1341754: Provide a valid triggeringPrincipal when calling SetURI in Location. r=smaug draft
Christoph Kerschbaumer <ckerschb@christophkerschbaumer.com> - Wed, 01 Mar 2017 19:20:52 +0100 - rev 494704
Push 48103 by masayuki@d-toybox.com at Tue, 07 Mar 2017 18:03:14 +0000
Bug 1341754: Provide a valid triggeringPrincipal when calling SetURI in Location. r=smaug MozReview-Commit-ID: 6q6V5ytCpcv
74a49c067dce8277a299bcebda68ca296c799fe1: Bug 1335475 - Switch browser_tab_dragdrop.js to load a plugin from HTTP instead of a no-privilege data: URI which doesn't work any more. Also re-enable this test on Linux now that we don't have windowed-mode plugins any more, so this won't assert (undo bug 1331320). r?jaws draft
Benjamin Smedberg <benjamin@smedbergs.us> - Tue, 07 Mar 2017 11:11:54 -0500 - rev 494703
Push 48102 by bsmedberg@mozilla.com at Tue, 07 Mar 2017 18:00:58 +0000
Bug 1335475 - Switch browser_tab_dragdrop.js to load a plugin from HTTP instead of a no-privilege data: URI which doesn't work any more. Also re-enable this test on Linux now that we don't have windowed-mode plugins any more, so this won't assert (undo bug 1331320). r?jaws MozReview-Commit-ID: D6JzYliULPG
3cd6470ea50027d16bcfbf8c8e540cc2be5e76db: Bug 1318312 part.3 Selection should move focus at every selection change when it's called by JS r?smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Mar 2017 02:31:08 +0900 - rev 494702
Push 48101 by masayuki@d-toybox.com at Tue, 07 Mar 2017 17:56:27 +0000
Bug 1318312 part.3 Selection should move focus at every selection change when it's called by JS r?smaug Selection may be changed by methods of Selection or methods of Range retrieved by Selection.getRangeAt(). Selection::NotifySelectionListeners() is called after every selection change of each of them, so, this method must be a good point to move focus. If new common ancestor of all ranges is editable and in an editing host, we should move focus to it. Otherwise, if an editing host has focus but new common ancestor is not editable, we should move focus from the editing host. For consistency with the other browsers, this patch doesn't move focus to other focusable element. MozReview-Commit-ID: 6sNsuzwqECX
ebad7b29c6a5b61944642ffa3d26ec3ed4ba25c6: Bug 1318312 part.2 Mark Selection as "called from JS" when every Selection API which may cause changing selection is called from JS r?smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Mar 2017 00:57:44 +0900 - rev 494701
Push 48101 by masayuki@d-toybox.com at Tue, 07 Mar 2017 17:56:27 +0000
Bug 1318312 part.2 Mark Selection as "called from JS" when every Selection API which may cause changing selection is called from JS r?smaug Selection needs to be able to distinguish if every selection change is caused by JS (via Selection API) or the others. This patch maps some methods of Range and Selection to *JS(). Each of them marks its instance as "used by JS" and calls corresponding method. With this change, Selection::NotifySelectionListeners() can move focus only when it's caused by Selection API. MozReview-Commit-ID: 1GoLHiIJ10Y
8b2d7590eb86a748a6c16fdc422b1fe332698bbc: Bug 1318312 part.1 Add automated tests for checking focus move at using Selection API r?smaug draft
Masayuki Nakano <masayuki@d-toybox.com> - Wed, 08 Mar 2017 02:35:59 +0900 - rev 494700
Push 48101 by masayuki@d-toybox.com at Tue, 07 Mar 2017 17:56:27 +0000
Bug 1318312 part.1 Add automated tests for checking focus move at using Selection API r?smaug Adding automated tests as web platform tests (only for mozilla) for focus move at using Selection API. Although, there is no standards of relation between Selection API and focus, we should move focus when Selection API moves selections into only an editing host or outside of focused editing host. Chrome moves focus as this rules, therefore, user can modify contenteditable editor immediately after web app moves selection. Edge does NOT move focus at using Selection API. However, user can modify contenteditable editor similar to Chrome. We can guess that Edge doesn't need to move focus in its design because perhaps, Edge decides if it's editable only with primary selected range. We cannot take the Edge behavior due to our editor design. So, we can take only Chrome's approach for improving the compatibility. MozReview-Commit-ID: JuLiSMgqODm
f7985dc13d89cdbd271c26fcd0d455eb820097af: Bug 1334782 - Convert title to MatchGlob and title param to regex - cleanup code draft
BharatR123 <bharatraghunthan9767@gmail.com> - Tue, 07 Mar 2017 23:20:59 +0530 - rev 494699
Push 48100 by bmo:bharatraghunthan9767@gmail.com at Tue, 07 Mar 2017 17:54:05 +0000
Bug 1334782 - Convert title to MatchGlob and title param to regex - cleanup code MozReview-Commit-ID: sUA2hU43GM
426b8e141dc88a0794f6ea6516b26539bc039656: Bug 1342310 - preserve grid highlighter only when reloading the page;r=zer0 draft
Julian Descottes <jdescottes@mozilla.com> - Mon, 06 Mar 2017 19:19:58 +0100 - rev 494698
Push 48099 by jdescottes@mozilla.com at Tue, 07 Mar 2017 17:35:50 +0000
Bug 1342310 - preserve grid highlighter only when reloading the page;r=zer0 Store url in highlighters-overlay grid state to avoid reapplying a state after navigating on a different page. MozReview-Commit-ID: 6rTsAPuPhvx
ed3ccedd8f65d745c036b361c005087ca21da8de: Bug 1342310 - read grid color from highlighters-overlay state;r=gl draft
Julian Descottes <jdescottes@mozilla.com> - Mon, 06 Mar 2017 20:05:46 +0100 - rev 494697
Push 48099 by jdescottes@mozilla.com at Tue, 07 Mar 2017 17:35:50 +0000
Bug 1342310 - read grid color from highlighters-overlay state;r=gl - emit highlighter options when emitting grid highlighter shown/hidden events - read color for highlighted grid container when building initial grids array in grid-inspector - explicitly set color when toggling grid highlighter from the rule view MozReview-Commit-ID: IqvnSdJfq9u
e6a74f6cf53db2b46ac8dad4e1655e4e88ccd975: Bug 1342310 - remember selected grid container on navigate;r=gl draft
Julian Descottes <jdescottes@mozilla.com> - Thu, 02 Mar 2017 18:16:47 +0100 - rev 494696
Push 48099 by jdescottes@mozilla.com at Tue, 07 Mar 2017 17:35:50 +0000
Bug 1342310 - remember selected grid container on navigate;r=gl The highlighters-overlay now keep the state of the grid highlighter in memory. On "navigate", the state is restored. MozReview-Commit-ID: 7KNhxHs3L5G
269d1e9c93cbed27247d96b9549b1fec48df009e: Bug 1344308 - Extend toolkit's eslint rules and fix lint errors in PSM draft
Sam Foster <sfoster@mozilla.com> - Tue, 07 Mar 2017 09:29:44 -0800 - rev 494695
Push 48098 by bmo:sfoster@mozilla.com at Tue, 07 Mar 2017 17:30:45 +0000
Bug 1344308 - Extend toolkit's eslint rules and fix lint errors in PSM * Remove eslint rules for PSM which are redundant with toolkit/.eslintrc.js * Fix missing plugins block in mochitest.eslintrc.js * Disable brace-style checking in mixed-content mochitests which use boilerplate where calls to runTest and afterNavigationTest all use opening brace on newline. I've left this for a follow-up. * Fix lint errors resulting from new rules defined by toolkit's eslintrc.js MozReview-Commit-ID: 6DWz7oUpie6
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip