CMD + a number key is a keyboard shortcut to select that tab number. (CMD+9 will always select the right-most tab, regardless of the tab count.) Currently, if the number is greater than the tab count, then the keyboard shortcut is ignored. With this patch, the right-most tab will be selected instead. For example, if there are five tabs and the user accidentally enters CMD+6 instead of CMD+5, selecting tab #5 is probably what they wanted instead of ignoring the keyboard shortcut.
Also expand the tab selection tests to cover more edge cases.
This patch was generated by the command:
find * -type f -exec sed -i -f ../mozpropsub {} \;
in the root of the repository, with the file ../mozpropsub containing:
s/-moz-padding-end\>/padding-inline-end/g
s/-moz-padding-start\>/padding-inline-start/g
s/-moz-margin-end\>/margin-inline-end/g
s/-moz-margin-start\>/margin-inline-start/g
s/-moz-border-end\>/border-inline-end/g
s/-moz-border-end-color\>/border-inline-end-color/g
s/-moz-border-end-style\>/border-inline-end-style/g
s/-moz-border-end-width\>/border-inline-end-width/g
s/-moz-border-start\>/border-inline-start/g
s/-moz-border-start-color\>/border-inline-start-color/g
s/-moz-border-start-style\>/border-inline-start-style/g
s/-moz-border-start-width\>/border-inline-start-width/g
s/\<MozPaddingEnd\>/paddingInlineEnd/g
s/\<MozPaddingStart\>/paddingInlineStart/g
s/\<MozMarginEnd\>/marginInlineEnd/g
s/\<MozMarginStart\>/marginInlineStart/g
s/\<MozBorderEnd\>/borderInlineEnd/g
s/\<MozBorderEndColor\>/borderInlineEndColor/g
s/\<MozBorderEndStyle\>/borderInlineEndStyle/g
s/\<MozBorderEndWidth\>/borderInlineEndWidth/g
s/\<MozBorderStart\>/borderInlineStart/g
s/\<MozBorderStartColor\>/borderInlineStartColor/g
s/\<MozBorderStartStyle\>/borderInlineStartStyle/g
s/\<MozBorderStartWidth\>/borderInlineStartWidth/g
The diffs for the following files:
layout/style/nsCSSPropAliasList.h
layout/style/test/property_database.js
layout/style/test/test_value_computation.html
were then manually removed from the patch.
MozReview-Commit-ID: 8fbYnlZcn9U
userTypedClear was used for two cases:
1) to keep track of whether we were in the middle of a loadURI call. This use is replaced by inLoadURI, which is
more sane when using e10s (though it's hard to be precise there because we're sending all web navigation calls to
the content process and this introduces a degree of asynchronousness that we just have to live with...).
2) to keep track of whether we were between a network start and a corresponding network stop, and whether the user
typed since the load properly started. This is now tracked on a small object on the browser binding, which has
appropriately named method so we're not just incrementing some magic number but actually understand what
we're saying, and so the information we get out (did the user type since this load started or not?) makes sense.
Note that we're keeping userTypedClear in session store information in order to remain backwards compatible.
It becomes a simple boolean-stored-as-int (1 or 0) that indicates whether we quit/crashed/stopped while a load
was pending, or not.
MozReview-Commit-ID: 5NbmVueocC7
--HG--
extra : rebase_source : 55cd9f3513c0a985580957a5157d47853a8822bf
extra : source : 386b9c750bd2ed458112acd29eb72e4e1371af9d
userTypedClear was used for two cases:
1) to keep track of whether we were in the middle of a loadURI call. This use is replaced by inLoadURI, which is
more sane when using e10s (though it's hard to be precise there because we're sending all web navigation calls to
the content process and this introduces a degree of asynchronousness that we just have to live with...).
2) to keep track of whether we were between a network start and a corresponding network stop, and whether the user
typed since the load properly started. This is now tracked on a small object on the browser binding, which has
appropriately named method so we're not just incrementing some magic number but actually understand what
we're saying, and so the information we get out (did the user type since this load started or not?) makes sense.
Note that we're keeping userTypedClear in session store information in order to remain backwards compatible.
It becomes a simple boolean-stored-as-int (1 or 0) that indicates whether we quit/crashed/stopped while a load
was pending, or not.
MozReview-Commit-ID: 5NbmVueocC7
--HG--
extra : rebase_source : f87199c77094c24c132e6c88f751a5b5d5aa62f9
Most of this is fixing functions that in some cases return a value but then
can also run to completion without returning anything. ESLint 2 catches this
where previous versions didn't. Unless there was an obvious other choice I just
made these functions return undefined at the end which is effectively what
already happens.
MozReview-Commit-ID: DEskVIjiKDM
--HG--
extra : rebase_source : 07ba1d14655f5d761624b105ef025ec88323d4d5
extra : histedit_source : 9e5ab54ce1b1a5ee1f0fb143f8d1450522455e3b
