223ff75af17c58cd1c588db44819d6ac4ab8ddb3: Bug 1334239 - Baldr: emit trap out-of-line paths in function import wrappers (r=bbouvier)
Luke Wagner <luke@mozilla.com> - Thu, 02 Feb 2017 14:33:10 -0600 - rev 361381
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1334239 - Baldr: emit trap out-of-line paths in function import wrappers (r=bbouvier) MozReview-Commit-ID: JViJfj2cZpG
fb57bb8234adb76e65e11a3d0a00740cc7de10fd: Bug 1334239 - Baldr: re-enable SigIdDesc immediate optimization (r=bbouvier)
Luke Wagner <luke@mozilla.com> - Thu, 02 Feb 2017 14:33:07 -0600 - rev 361380
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1334239 - Baldr: re-enable SigIdDesc immediate optimization (r=bbouvier) MozReview-Commit-ID: H8WJ8nandop
3d1891948fe9f337f4af1df67b5c1b6cc107a4b0: Bug 1334239 - Baldr: use word-size comparison for signature pointer (r=bbouvier)
Luke Wagner <luke@mozilla.com> - Thu, 02 Feb 2017 14:33:04 -0600 - rev 361379
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1334239 - Baldr: use word-size comparison for signature pointer (r=bbouvier) MozReview-Commit-ID: 1XyLkUTWKm0
28bb04d0338d2741bbc951566f156744a50060bc: Bug 1333631 - Fix misuse of nsIFile::GetNativeTarget in dom/filesystem. r=baku
Masatoshi Kimura <VYV03354@nifty.ne.jp> - Fri, 27 Jan 2017 00:48:52 +0900 - rev 361378
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1333631 - Fix misuse of nsIFile::GetNativeTarget in dom/filesystem. r=baku MozReview-Commit-ID: 9VpLg1iNFxs
b3d2a4cdecd15085d59d2d5fc7661392fb771787: Bug 1336028 NativeKey::GetFollowingCharMessage() should take newer char message when found char message and removed message from the queue is different but their scancode indicates same physical key r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 02 Feb 2017 23:28:48 +0900 - rev 361377
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1336028 NativeKey::GetFollowingCharMessage() should take newer char message when found char message and removed message from the queue is different but their scancode indicates same physical key r=m_kato NativeKey::GetFollowingCharMessage() may remove a char message which is different from previously found message in the queue because hacky keyboard layout or utility can overwrite the wParam when it's removed from the queue. Now, we should assume that newer message, i.e., actually removed from the queue, is the expected message by the user. See bug 1336028 comment 0 for the actual scenarios which are collected by crash reports. https://bugzilla.mozilla.org/show_bug.cgi?id=1336028#c0 MozReview-Commit-ID: 9ZgukHH1vfi
26268dace54f614d06554596c3c8967b957418db: Merge m-c to autoland
Phil Ringnalda <philringnalda@gmail.com> - Thu, 02 Feb 2017 22:11:54 -0800 - rev 361376
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Merge m-c to autoland
460ffe0d627154d12deff6c96278b42cb5501101: Bug 1330823 Part 2 permission prompts for interactive extension updates r=florian,mossop
Andrew Swan <aswan@mozilla.com> - Wed, 01 Feb 2017 19:51:10 -0800 - rev 361375
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1330823 Part 2 permission prompts for interactive extension updates r=florian,mossop MozReview-Commit-ID: HI41MbwkqW6
e1839ba084c88fefa2467c6dd7e64b200ce3489e: Bug 1330823 Part 1 refactor some existing permissions code r=mossop
Andrew Swan <aswan@mozilla.com> - Thu, 02 Feb 2017 16:57:29 -0800 - rev 361374
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1330823 Part 1 refactor some existing permissions code r=mossop This patch is just cleanups that don't alter any current behavior but make the changes for updates in part 2 simpler. MozReview-Commit-ID: 18QEx7RxWxH
b3d1819dc7b463c3c28be21ac72f74c60c700c68: Merge m-c to autoland
Phil Ringnalda <philringnalda@gmail.com> - Thu, 02 Feb 2017 21:12:12 -0800 - rev 361373
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Merge m-c to autoland CLOSED TREE
8c32b1b8aa9218ce143ad42671cbe3a42ad17327: Backed out 5 changesets (bug 1328058) for timing out in browser_block_silentAudioTrack_media.js
Phil Ringnalda <philringnalda@gmail.com> - Thu, 02 Feb 2017 20:59:34 -0800 - rev 361372
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Backed out 5 changesets (bug 1328058) for timing out in browser_block_silentAudioTrack_media.js CLOSED TREE Backed out changeset 0c48cff3db5d (bug 1328058) Backed out changeset 37d35ca95b1f (bug 1328058) Backed out changeset 0c177bdf5ec3 (bug 1328058) Backed out changeset b369d9999b8a (bug 1328058) Backed out changeset 61dbcbe35565 (bug 1328058)
5d641acb1f4ec08ea58ac83cd1359db19176a270: Bug 1335670 NativeKey should dispatch consumed keydown event when it receives WM_NULL at removing WM_*CHAR from the queue and the original message has gone r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Thu, 02 Feb 2017 22:43:20 +0900 - rev 361371
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1335670 NativeKey should dispatch consumed keydown event when it receives WM_NULL at removing WM_*CHAR from the queue and the original message has gone r=m_kato Currently, NativeKey::GetFollowingCharMessage() tries 5 times to remove found char message from the queue. It was enough when we found this issue at developing Metrofox. However, this hack is not enough for some odd keyboard layouts because we see some crash reports which gives up to remove a char message from the queue because 5 WM_NULL messages are returned. For preventing this crash, we should check if there is the message which is trying to remove from the queue when NativeKey receives WM_NULL. Then, when there is no key message in the queue or next key message becomes non-char message,, NativeKey should dispatch consumed keydown event because we can assume that the key operation may have already been handled or canceled. Otherwise, NativeKey should retry to remove the message again (until 50 times!, it's just enough big magic number, there is no concrete reason). MozReview-Commit-ID: 1c6Y4OoQdrP
0c48cff3db5d9e904c943694e24cdd0b6565c45d: Bug 1328058 followup, address eslint's concerns about a single-quoted string on a CLOSED TREE
Phil Ringnalda <philringnalda@gmail.com> - Thu, 02 Feb 2017 19:59:01 -0800 - rev 361370
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1328058 followup, address eslint's concerns about a single-quoted string on a CLOSED TREE
f727429bff74d3385b01ebe6bd55501122c6b47d: Bug 1335295 - [EME] Add pref to override EME decrypt/decode with blank decoder. r=jya
Chris Pearce <cpearce@mozilla.com> - Tue, 31 Jan 2017 15:42:45 +1300 - rev 361369
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1335295 - [EME] Add pref to override EME decrypt/decode with blank decoder. r=jya This means we can isolate whether a playback failure is in the audio or video stream. MozReview-Commit-ID: G4broHPaAkX
1deef84b366352b1deb66b4d19e0ab23b8d92527: Bug 1336009 - null Java object check before accessing. r=jchen
John Lin <jolin@mozilla.com> - Thu, 02 Feb 2017 17:14:10 +0800 - rev 361368
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1336009 - null Java object check before accessing. r=jchen MozReview-Commit-ID: 8Wkr2nnXacs
37d35ca95b1fd6efbd576190d007a2ec6e6c90c0: Bug 1328058 - part4 : add tests. r=baku
Alastor Wu <alwu@mozilla.com> - Fri, 03 Feb 2017 11:25:10 +0800 - rev 361367
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1328058 - part4 : add tests. r=baku MozReview-Commit-ID: 2Gjh0dBHroI
0c177bdf5ec302d937f1c428e78c3ad2a96ed838: Bug 1328058 - part3 : don't show the sound indicator for video with silent audio track r=baku
Alastor Wu <alwu@mozilla.com> - Fri, 03 Feb 2017 11:25:08 +0800 - rev 361366
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1328058 - part3 : don't show the sound indicator for video with silent audio track r=baku After resume the tab, we shouldn't show sound indicator directly because we don't know whether the blocked media is audible or not. MozReview-Commit-ID: KccDtzTNmx3
b369d9999b8a7dcaf4809ff9697f03e47d0ef393: Bug 1328058 - part2 : rename function. r=baku
Alastor Wu <alwu@mozilla.com> - Fri, 03 Feb 2017 11:25:06 +0800 - rev 361365
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1328058 - part2 : rename function. r=baku Rename function MaybeNotifyMediaBlocked() to MaybeNotifyMediaBlockStart(). MozReview-Commit-ID: CJyWiKKkpwd
61dbcbe35565c51cbc50f1123bee7c383731cd7c: Bug 1328058 - part1 : notify block-stop event when the tab was resumed. r=baku
Alastor Wu <alwu@mozilla.com> - Fri, 03 Feb 2017 11:25:04 +0800 - rev 361364
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1328058 - part1 : notify block-stop event when the tab was resumed. r=baku In present design, the tab would hide the unblocking icon when receives the audio-playback event, but it means we can't hide the icon if the media isn't audible. For example, we won't show the unblocking icon for audio with audio track, but we show the icon for audio with silent audio track which can only be detected after starting decoding. In this case, we can't receive the audio-playback after resuming that media. Therefore, we should dispatch the different event to notify tab UI that the tab has already been resumed. MozReview-Commit-ID: 3xCWQU7nVCl
9d882c051d0043250bf4a196411abdba4ff5709c: Bug 1319771 - part2 : resume foreground window if it was still be blocked. r=baku
Alastor Wu <alwu@mozilla.com> - Fri, 03 Feb 2017 10:50:07 +0800 - rev 361363
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1319771 - part2 : resume foreground window if it was still be blocked. r=baku In previous patch, we modify the behavior of nsDocument, now it would only resume window when document has active media components. However, it causes another issue. If the tab really goes to foreground, but there is no active media component, the tab would still be blocked and it won't be resumed anymore. Therefore, we need to resume it by ourself if the tab is on the foreground but doesn't be resumed yet. MozReview-Commit-ID: EdnQ7sRkSJK
7302c447d09afb58837338a023a31458d720a531: Bug 1319771 - part1 : only resume the window when there has active media components. r=baku
Alastor Wu <alwu@mozilla.com> - Fri, 03 Feb 2017 10:48:38 +0800 - rev 361362
Push 10863 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 23:02:23 +0000
Bug 1319771 - part1 : only resume the window when there has active media components. r=baku For the first pinned tab, it would be set to visible first and then set to invisible if there exists other tabs after restarting the whole browser. If the tab is set to visible, we would activate the media component (set the |mMediaSuspended| in outer window to none-suspend). In this case, the first pinned tab would be set to visible briefly, but it doesn't mean the tab is in the foreground, it's just how DOM manage the tab's visibility. In that moment, none of the media component has been created yet. Therefore, we would only activate the media component after the audio channel service exists. MozReview-Commit-ID: 1FgdMq84yWX
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 tip