b12188aa6424b28932fd16f2d06b0984e711fe96: Bug 1461522 - Add ID and class properties to HTMLTooltip; r?jdescottes draft
Brian Birtles <birtles@gmail.com> - Thu, 28 Jun 2018 15:13:05 +0900 - rev 813901
Push 115042 by bbirtles@mozilla.com at Wed, 04 Jul 2018 04:36:27 +0000
Bug 1461522 - Add ID and class properties to HTMLTooltip; r?jdescottes In particular, the ID allows us to associate the tooltip with the button that triggers it using the aria-controls attribute. MozReview-Commit-ID: ArjH2s5JNlC
09e2cec1dac879fcf503cbc799bdc5f5f794b65e: Bug 1461522 - Add focus() and focusEnd() methods to HTMLTooltip; r?jdescottes draft
Brian Birtles <birtles@gmail.com> - Thu, 28 Jun 2018 15:10:42 +0900 - rev 813900
Push 115042 by bbirtles@mozilla.com at Wed, 04 Jul 2018 04:36:27 +0000
Bug 1461522 - Add focus() and focusEnd() methods to HTMLTooltip; r?jdescottes We will use these methods later when we put menu content inside HTMLTooltip in order to set the initial focus. MozReview-Commit-ID: HR02wg543gP
04040a4a430c590cfe90525c894abe685428ed9c: Bug 1461522 - Factor out a focusableSelector utility; r?jdescottes draft
Brian Birtles <birtles@gmail.com> - Thu, 28 Jun 2018 15:10:27 +0900 - rev 813899
Push 115042 by bbirtles@mozilla.com at Wed, 04 Jul 2018 04:36:27 +0000
Bug 1461522 - Factor out a focusableSelector utility; r?jdescottes We will use this later when we introduce a MenuList class since it will want to manage focus for its menu items. This patch also extends the definition of focusable elements somewhat. MozReview-Commit-ID: 3shnC0t79rF
9544afc6116630a97af5f79cd91ee5756bf3b727: Bug 1461522 - Add doorhanger type to HTMLTooltip; r?jdescottes draft
Brian Birtles <birtles@gmail.com> - Thu, 28 Jun 2018 15:04:13 +0900 - rev 813898
Push 115042 by bbirtles@mozilla.com at Wed, 04 Jul 2018 04:36:27 +0000
Bug 1461522 - Add doorhanger type to HTMLTooltip; r?jdescottes MozReview-Commit-ID: 6Oq9qauwngX
14ca57e648d6d647dfdaf2f9857e97ba5bd90aed: Bug 1461522 - Allow { height: "auto" } in HTMLTooltip setContent and make it the default; r?jdescottes draft
Brian Birtles <birtles@gmail.com> - Thu, 28 Jun 2018 15:03:57 +0900 - rev 813897
Push 115042 by bbirtles@mozilla.com at Wed, 04 Jul 2018 04:36:27 +0000
Bug 1461522 - Allow { height: "auto" } in HTMLTooltip setContent and make it the default; r?jdescottes The current default value for height of Infinity has the unfortunate side effect that, when combined with using a XUL wrapper, there will be a large filler element stretching vertically on one side of the tooltip that effectively neuters all content beneath it. While this is probably fine for tooltips that are shown on hover, it is problematic if we want to use this for DevTools menus because it means the user is unable to click anything above/below the menu so long as it is open (which can be particularly problematic once we make HTMLTooltip support the "Disable popup autohide" feature"). Even if we were to decide that clicks outside the tooltip should be consumed anyway we would still have the problem that hover styles don't apply in this "dead" region. As a result, this patch makes the { height: Infinity } behaviour opt-in for those tooltips that really need it. For most uses, however, a height calculated when the tooltip is shown should be sufficient (and later in this patch series we will add a mechanism to HTMLTooltip to explicitly request it recalculate its size and position in response to content changes). This patch introduces the { height: "auto" } mechanism and also reverses the order in which size/position properties are calculated to match the regular manner in which layout is performed: widths first, then heights. MozReview-Commit-ID: 7BeVkxGVhYn
01dce05cc1af0e1706c0bf7e1ec79af1dad68b37: Bug 1461522 - Fix some comments in HTMLTooltip.js; r?jdescottes draft
Brian Birtles <birtles@gmail.com> - Thu, 28 Jun 2018 14:56:30 +0900 - rev 813896
Push 115042 by bbirtles@mozilla.com at Wed, 04 Jul 2018 04:36:27 +0000
Bug 1461522 - Fix some comments in HTMLTooltip.js; r?jdescottes MozReview-Commit-ID: F01ofl9u5lR
9f707175c1b9aaa8fca749123329e6d307c82668: Bug 1461522 - Use the currentZoom as opposed to the pref value; r?jdescottes draft
Brian Birtles <birtles@gmail.com> - Thu, 28 Jun 2018 14:55:48 +0900 - rev 813895
Push 115042 by bbirtles@mozilla.com at Wed, 04 Jul 2018 04:36:27 +0000
Bug 1461522 - Use the currentZoom as opposed to the pref value; r?jdescottes In a couple of places in DevTools we read back the value of the "devtools.toolbox.zoomValue" pref and take that to be the zoom value. However, at certain zoom levels these two can differ: the pref value representing the ideal zoom and currentZoom giving the actual zoom value in use. This patch makes us use the actual zoom value in the two places where this occurs. Unfortunately, we cannot easily adjust the browser_html_tooltip_zoom.js test for this since it uses a separate XUL document that does not take into account the pref value---as a result that test directly sets the currentZoom on the separate doc and hence this problem won't occur. Instead, this patch adjusts the browser_toolbox_zoom_popup.js test since the toolbox menu positioning uses the same problematic pattern so we can reproduce the bug in the browser_toolbox_zoom_popup.js. (This patch fixes both occurances of this pattern.) At least locally browser_toolbox_zoom_popup.js passes for me with a zoom of 1.5 but fails with a zoom of 1.4. Similarly in my testing of HTMLTooltip, zoom values such as 1.2 and 1.4 often show significant misalignment whilst a zoom of 1.3 or 1.5 is fine. With the code changes in this patch, the test passes with any given zoom factor. (This patch also incidentally replaced isNaN with the more robust Number.isNaN.) MozReview-Commit-ID: JmlRoidARVp
b0dfde84ac8da67818e101fb132a278e433dd33d: Bug 1461522 - Make HTMLTooltip position the arrow correctly in RTL mode; r?jdescottes draft
Brian Birtles <birtles@gmail.com> - Thu, 28 Jun 2018 14:52:10 +0900 - rev 813894
Push 115042 by bbirtles@mozilla.com at Wed, 04 Jul 2018 04:36:27 +0000
Bug 1461522 - Make HTMLTooltip position the arrow correctly in RTL mode; r?jdescottes Currently the arrow offset is not correctly positioned in RTL mode as evidenced by the test case included in this patch (which fails without the code changes included in this patch). This patch logicalizes the calculations for positioning the tooltip which fixes this and other issues when using RTL mode and will make it easier to introduce a new "doorhanger" type tooltip later in this patch series. MozReview-Commit-ID: BQXhDHbPTbl
6aaf7e68a13ffc3cb3318c1fc3b2b8f609579104: Bug 1403027 - Do not throw from PerformanceObserver.observe when none of the entryTypes are known (log a JS console warning instead); r?bz draft
Thomas Wisniewski <wisniewskit@gmail.com> - Wed, 24 Jan 2018 20:59:04 -0500 - rev 813893
Push 115041 by wisniewskit@gmail.com at Wed, 04 Jul 2018 02:50:04 +0000
Bug 1403027 - Do not throw from PerformanceObserver.observe when none of the entryTypes are known (log a JS console warning instead); r?bz MozReview-Commit-ID: Lx2cjWDX8sh
65b004eda9db7133ae165744604f5d5bc93a1199: Bug 1470932 - Get principal from nsGlobalWindowInner directly in MediaManaager::IsActivelyCapturingOrHasAPermission(). r?jib draft
Chris Pearce <cpearce@mozilla.com> - Wed, 04 Jul 2018 12:53:18 +1200 - rev 813892
Push 115040 by bmo:cpearce@mozilla.com at Wed, 04 Jul 2018 02:24:28 +0000
Bug 1470932 - Get principal from nsGlobalWindowInner directly in MediaManaager::IsActivelyCapturingOrHasAPermission(). r?jib nsGlobalWindowInner::GetExtantDoc() can potentially return null, and we're not null checking its return value in MediaManaager::IsActivelyCapturingOrHasAPermission() which I think is the cause of this crash. So instead of getting the principal from the window's extant doc, we can get the principal directly from the nsGlobalWindowInner. MozReview-Commit-ID: BUwiJGLss2a
91b394896bf500206ac08de8943f9f1a6256436f: Bug 1470932 - Get principal from window inner directly in MediaManaager::IsActivelyCapturingOrHasAPermission(). r?jib draft
Chris Pearce <cpearce@mozilla.com> - Wed, 04 Jul 2018 12:53:18 +1200 - rev 813891
Push 115039 by bmo:cpearce@mozilla.com at Wed, 04 Jul 2018 02:22:37 +0000
Bug 1470932 - Get principal from window inner directly in MediaManaager::IsActivelyCapturingOrHasAPermission(). r?jib nsGlobalWindowInner::GetExtantDoc() can potentially return null, and we're not null checking its return value in MediaManaager::IsActivelyCapturingOrHasAPermission() which I think is the cause of this crash. So instead of getting the principal from the windows extant doc, we can get the principal directly from the inner window. MozReview-Commit-ID: BUwiJGLss2a
16e3ee6b12e9e67913b98b8a38614a3e820e780d: Bug 1471485 - Hide autoplay permission doorhanger if user plays video. r?johannh draft
Chris Pearce <cpearce@mozilla.com> - Tue, 03 Jul 2018 11:17:16 +1200 - rev 813890
Push 115039 by bmo:cpearce@mozilla.com at Wed, 04 Jul 2018 02:22:37 +0000
Bug 1471485 - Hide autoplay permission doorhanger if user plays video. r?johannh If we're showing a permission UI prompt for "autoplay-media", the user can still actually play media without interacting with the doorhanger; if they click a "play" button in the document, they'll "gesture activate" the document and unblock autoplay and be able to start playback. It doesn't make sense to keep showing the permission doorhanger to approve autoplay when the page is already playing, as playback has already started, and if they clicked on "block" then the site would receive a promise reject on the promise returned on the first call to HTMLMediaElement.play() for which we were showing the permission prompt for, even though the media is actually playing. This will likely confuse JS video players. So we should hide the permission prompt when playback in the page starts. MozReview-Commit-ID: 1XU47AfT6vf
922d5011fd419da6ba3a3f44a11ac2ef959d2588: Bug 1472580 - Test that starting play from tab audio indicator overrides block autoplay. r=mconley draft
Chris Pearce <cpearce@mozilla.com> - Mon, 25 Jun 2018 13:25:34 +1200 - rev 813889
Push 115039 by bmo:cpearce@mozilla.com at Wed, 04 Jul 2018 02:22:37 +0000
Bug 1472580 - Test that starting play from tab audio indicator overrides block autoplay. r=mconley MozReview-Commit-ID: 6RB09cd1PHP
fd4eb3e5a348ef7425320c6502af21c1f844007a: Bug 1472580 - Gesture activate documents which are played via the tab audio indicator. r=mconley draft
Chris Pearce <cpearce@mozilla.com> - Wed, 04 Jul 2018 09:32:22 +1200 - rev 813888
Push 115039 by bmo:cpearce@mozilla.com at Wed, 04 Jul 2018 02:22:37 +0000
Bug 1472580 - Gesture activate documents which are played via the tab audio indicator. r=mconley (This patch was first presented for review in bug 1463919, I've split it off into its own bug here). If the user opens a tab in the background, and that tab tries to play media, we'll delay playing that media until the tab is brought to the foreground. But the user can explicitly start playback of such delayed media by clicking the "play" icon we show in the tab indicator. Then if autoplay is disabled, we'll block the play (unless the origin is whitelisted). This is bad, as the user has clearly indicated intent to play media in this tab. So this patch "gesture activates" the root content document when the tab audio indicator play button is pressed. This means the block autoplay logic will behave as if there's been a user gesture in the tab (mouse click or keypress), and not block the play. Gesture activation state is per document, so it does not persist across document loads. MozReview-Commit-ID: 3pgrADRrJqt *** fix
ccba4588f9d27c2444f75987cfb545438e4716dd: Bug 1473201: Change fill-opacity for color path to show actual color. r?jdescottes draft
Daisuke Akatsuka <dakatsuka@mozilla.com> - Wed, 04 Jul 2018 11:19:10 +0900 - rev 813887
Push 115038 by bmo:dakatsuka@mozilla.com at Wed, 04 Jul 2018 02:19:48 +0000
Bug 1473201: Change fill-opacity for color path to show actual color. r?jdescottes MozReview-Commit-ID: HlDpuKkM5Se
36a0deca706a28e3226b6349a44108ace9af7329: Bug 1473200: Provide accessibility context for permission controls in the identity popup. r?johannh draft
James Teh <jteh@mozilla.com> - Wed, 04 Jul 2018 12:13:51 +1000 - rev 813886
Push 115037 by bmo:jteh@mozilla.com at Wed, 04 Jul 2018 02:18:27 +0000
Bug 1473200: Provide accessibility context for permission controls in the identity popup. r?johannh The containers are given an ARIA role of group and labels are associated using aria-labelledby. For example, this allows screen reader users to know which permission each control is associated with. Otherwise, they might hear only "Clear this permission and ask again button", with no knowledge of what the permission is. MozReview-Commit-ID: LeiOmz6go9l
4364fc5c138ec8f8947732d95940a1cb39509242: Bug 1472684: Hide info bar and guides from highlighter. r?gl draft
Daisuke Akatsuka <dakatsuka@mozilla.com> - Wed, 04 Jul 2018 10:50:12 +0900 - rev 813885
Push 115036 by bmo:dakatsuka@mozilla.com at Wed, 04 Jul 2018 01:50:57 +0000
Bug 1472684: Hide info bar and guides from highlighter. r?gl MozReview-Commit-ID: AAchCYg0d61
d82e5c726da254420d02f63bc671d1a3c5c5e4f2: Bug 1472859 - Part 2: Add test for same colors and currentcolor. r?gl draft
Daisuke Akatsuka <dakatsuka@mozilla.com> - Wed, 04 Jul 2018 10:34:18 +0900 - rev 813884
Push 115036 by bmo:dakatsuka@mozilla.com at Wed, 04 Jul 2018 01:50:57 +0000
Bug 1472859 - Part 2: Add test for same colors and currentcolor. r?gl MozReview-Commit-ID: KRnajXPdwSq
64d24661bfbb0357c5461171e364e4c74ef6a27b: Bug 1472859 - Part 1: Avoid crashing which is in case the all values of keyframes are same. r?gl draft
Daisuke Akatsuka <dakatsuka@mozilla.com> - Wed, 04 Jul 2018 10:34:10 +0900 - rev 813883
Push 115036 by bmo:dakatsuka@mozilla.com at Wed, 04 Jul 2018 01:50:57 +0000
Bug 1472859 - Part 1: Avoid crashing which is in case the all values of keyframes are same. r?gl MozReview-Commit-ID: Bz60drhwohf
8a3d51c82a7f3f0197f965d3f16e1a14618df9ef: Bug 1416066 - Add a new flag to nsIAboutModule to load URIs in privileged content processes if feature is enabled. draft
imjching <jlim@mozilla.com> - Tue, 03 Jul 2018 19:31:37 -0400 - rev 813882
Push 115035 by bmo:jlim@mozilla.com at Wed, 04 Jul 2018 01:38:44 +0000
Bug 1416066 - Add a new flag to nsIAboutModule to load URIs in privileged content processes if feature is enabled. We will apply the URI_CAN_LOAD_IN_PRIVILEGED_CHILD flag to Activity Stream about: pages instead of hardcoding the URLs in a Set. MozReview-Commit-ID: F6AGmsKs1SR
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 tip