3aadd635dda0633e3f970d06dbd46401817f13d0: Bug 1333930 - Disable ETC textures on ANGLE, where they are emulated. r=daoshengmu, a=ritu
Jeff Gilbert <jgilbert@mozilla.com> - Wed, 25 Jan 2017 14:13:15 -0800 - rev 375836
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 1333930 - Disable ETC textures on ANGLE, where they are emulated. r=daoshengmu, a=ritu MozReview-Commit-ID: EQL4jjQLmwO
d81e8306a13f8eda34dd0efa4d29d1cee1f54105: Bug 1120441 - Don't try to show tab-history panel if app has been shutdown. r=sebastian, a=ritu
Andrzej Hunt <ahunt@mozilla.com> - Wed, 18 Jan 2017 22:09:20 +0100 - rev 375835
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 1120441 - Don't try to show tab-history panel if app has been shutdown. r=sebastian, a=ritu Showing the tab history panel involves a gecko call to retrieve tab history. This can be slow, meaning we have no idea what state the app will be in when the tab history data is returned. Thus we need to protect the code that shows the tab history fragment against a number of scenarios to avoid crashes in those cases where the app might be shutting down: 1. If onSaveInstanceState() has been called (which might happen before or after onPause(), and might be linked to app shutdown - but the docs don't appear to give any guarantees), fragment transactions cannot be performed. We protect against this by accepting loss of state in fragment transactions. 2. If the Activity has been completely destroyed, trying to perform a fragment transaction will likewise fail. We protect against this by not even trying to perform the transaction if we definitively know that the Activity is being shut down (ie isFinishing()). In both of these cases, we simply must accept that we're potentially losing UI state: i.e. a user could request the tab history panel via long-back-press, followed by exiting the app; we now end up never ever showing the panel. This scenario doesn't seem like a major loss - and fixing this issue properly would require significant investment (i.e. we would need to either cache tab history on frontend side, or cache the tab-history panel request - and it's not clear users will still care about seeing the panel the next time they open firefox). MozReview-Commit-ID: JsAK1By8yqn
cb0502e9fcd7562a25d6e24b490bb9908042db7b: Bug 1333418 - Don't exceed index of KeyframeValueEntry more than entry's length. r=birtles, a=ritu
Hiroyuki Ikezoe <hikezoe@mozilla.com> - Mon, 30 Jan 2017 12:51:04 +0900 - rev 375834
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 1333418 - Don't exceed index of KeyframeValueEntry more than entry's length. r=birtles, a=ritu MozReview-Commit-ID: FMmUiWjtLDM
62764baa6ef6dec70b1f9248c6386eecc002ba7b: Bug 1334799 - Handle stack value in correct order when leaving for-of loop from finally block. r=shu, a=ritu
Tooru Fujisawa <arai_a@mac.com> - Sun, 29 Jan 2017 05:53:41 +0900 - rev 375833
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 1334799 - Handle stack value in correct order when leaving for-of loop from finally block. r=shu, a=ritu
900c746565fd10fb9feb7e28b6582030e77fee1b: Bug 1332664 - Cherry-pick upstream webrtc.org patch to not depend on 'experimental' includes for libvpx. r=rillian, a=ritu
Randell Jesup <rjesup@jesup.org> - Fri, 27 Jan 2017 21:10:58 -0500 - rev 375832
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 1332664 - Cherry-pick upstream webrtc.org patch to not depend on 'experimental' includes for libvpx. r=rillian, a=ritu
721ea96b25ca00a6c61683ded3d1779da5d46487: Bug 1307736 - Ensure tests performing a history load pass valid triggeringPrincipal. r=bz, r=mdeboer, a=ritu
Christoph Kerschbaumer <ckerschb@christophkerschbaumer.com> - Fri, 27 Jan 2017 11:19:45 +0100 - rev 375831
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 1307736 - Ensure tests performing a history load pass valid triggeringPrincipal. r=bz, r=mdeboer, a=ritu
664f2764b2be48ca5cfc115828d7006468f1d687: Bug 1307736 - Store triggeringPrincipal with all history entries. r=mdeboer, a=ritu
Christoph Kerschbaumer <ckerschb@christophkerschbaumer.com> - Fri, 27 Jan 2017 11:19:27 +0100 - rev 375830
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 1307736 - Store triggeringPrincipal with all history entries. r=mdeboer, a=ritu
f27e061cee9d2e6fc8f11bb2df254f365caca1ef: Bug 1307736 - Ensure History loads pass valid triggeringPrincipal. r=bz, a=ritu
Christoph Kerschbaumer <ckerschb@christophkerschbaumer.com> - Fri, 27 Jan 2017 11:19:13 +0100 - rev 375829
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 1307736 - Ensure History loads pass valid triggeringPrincipal. r=bz, a=ritu
b4ed5ea97d2553ad845bf31e746d767b4bffa50a: Bug 1276669 - Part 11: Strengthen assertions for atom table shutdown GC. r=erahm, a=ritu
Nathan Froyd <froydnj@mozilla.com> - Thu, 26 Jan 2017 16:43:38 -0400 - rev 375828
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 1276669 - Part 11: Strengthen assertions for atom table shutdown GC. r=erahm, a=ritu This could have been done more simply, but the small amount of refactoring that takes place in this comment enables better error messages in the case where something does go wrong.
8ee370bffd15ed59c401285dac62e7f24d4f15ef: Bug 1276669 - Part 10: Remove dynamic->static atom transmutation code. r=erahm, a=ritu
Nathan Froyd <froydnj@mozilla.com> - Thu, 26 Jan 2017 15:43:38 -0500 - rev 375827
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 1276669 - Part 10: Remove dynamic->static atom transmutation code. r=erahm, a=ritu Good riddance to some sketchy code.
2159ed149364daaadd4da371c00c4809cd5c3490: Bug 1276669 - Part 9: Forbid transmutation of dynamic atoms. r=erahm, a=ritu
Nathan Froyd <froydnj@mozilla.com> - Thu, 26 Jan 2017 15:43:38 -0500 - rev 375826
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 1276669 - Part 9: Forbid transmutation of dynamic atoms. r=erahm, a=ritu We can do this now that we've shuffled static atom initialization around appropriately.
712c0d0da7dce945cab161b7dcfa6e6ceec87ea3: Bug 1276669 - Part 8: Add a comment in NS_InitXPCOM2 to make static atom initialization less cryptic. r=erahm, a=ritu
Nathan Froyd <froydnj@mozilla.com> - Thu, 26 Jan 2017 15:43:38 -0500 - rev 375825
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 1276669 - Part 8: Add a comment in NS_InitXPCOM2 to make static atom initialization less cryptic. r=erahm, a=ritu This comment makes things slightly more greppable.
829c02ed316aebbbe061ec5c9f066e3d681f646e: Bug 1276669 - Part 7: Don't register static atoms after the table has been sealed. r=erahm, a=ritu
Nathan Froyd <froydnj@mozilla.com> - Thu, 26 Jan 2017 15:43:38 -0500 - rev 375824
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 1276669 - Part 7: Don't register static atoms after the table has been sealed. r=erahm, a=ritu This change seems like an obvious thing we should have been doing, but we weren't.
d5ccf239c1423f30e1a9ea1491a8ee7201ef199b: Bug 1276669 - Part 6: Seal the static atom table sooner. r=bz, a=ritu
Nathan Froyd <froydnj@mozilla.com> - Thu, 26 Jan 2017 15:43:38 -0500 - rev 375823
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 1276669 - Part 6: Seal the static atom table sooner. r=bz, a=ritu We do this to ensure that everybody has registered all the static atoms we'll care about, and to pave the way for asserting that nobody is trying to create any static atoms past this point in the next patch.
c1b5e94191ec94a36a2c01a161933ce7ee43d7e8: Bug 1276669 - Part 5: Don't try to test NS_RegisterStaticAtoms. r=erahm, a=ritu
Nathan Froyd <froydnj@mozilla.com> - Thu, 26 Jan 2017 15:43:39 -0500 - rev 375822
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 1276669 - Part 5: Don't try to test NS_RegisterStaticAtoms. r=erahm, a=ritu There are several XPCOM tests that purport to call NS_RegisterStaticAtoms. The tests located in the xpcom/tests/ directory are unused, so we might as well just remove them. The gtests do get run, but there's going to be no way to test NS_RegisterStaticAtoms once sealing the atom table actually means forbidding new additions. So we might as well remove the gtest too.
a5abb9c78e53ff6083c4e81cad93416b2492c8e9: Bug 1276669 - Part 4: Initialize RDF atoms in nsLayoutStatics. r=Pike, a=ritu
Nathan Froyd <froydnj@mozilla.com> - Thu, 26 Jan 2017 15:43:39 -0500 - rev 375821
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 1276669 - Part 4: Initialize RDF atoms in nsLayoutStatics. r=Pike, a=ritu This is not the cleanest code ever, but we need to move all static atom initialization prior to NS_SealStaticAtomTable to avoid the possibility of dynamic atoms being transmuted into static atoms. We therefore need to open up an avenue for somebody else to initialize the atoms that RDF needs.
c922a29ad1460b52ee197a8a285006aba1076996: Bug 1276669 - Part 3: Split out nsHTMLTags atom initialization. r=hsivonen, a=ritu
Nathan Froyd <froydnj@mozilla.com> - Thu, 26 Jan 2017 15:43:39 -0500 - rev 375820
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 1276669 - Part 3: Split out nsHTMLTags atom initialization. r=hsivonen, a=ritu We do this for much the same reason that we moved the nsHtml5Atoms initialization. Otherwise, the nsHTMLTags atoms are lazily initialized long after we've sealed the static atom table in nsLayoutStatics.
9feaa1d4b820f808154e306588b0cdfe6622c952: Bug 1276669 - Part 2: Move nsTextServicesDocument::RegisterAtoms call. r=bz, a=ritu
Nathan Froyd <froydnj@mozilla.com> - Thu, 26 Jan 2017 15:43:39 -0500 - rev 375819
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 1276669 - Part 2: Move nsTextServicesDocument::RegisterAtoms call. r=bz, a=ritu Moving this call closer to the other atom initializations will enable us to seal the static atom table sooner.
77ab0b39793686c3ce68e5e881973f9bdbd59fc3: Bug 1276669 - Part 1: Make nsHtml5Atoms initialization explicit in nsLayoutStatics. r=hsivonen, a=ritu
Nathan Froyd <froydnj@mozilla.com> - Thu, 26 Jan 2017 15:43:39 -0500 - rev 375818
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 1276669 - Part 1: Make nsHtml5Atoms initialization explicit in nsLayoutStatics. r=hsivonen, a=ritu Moving the html5 atoms out into their own initialization phase makes the initialization of atoms more explicit and avoids problems with trying to move modules around so their atoms get initialized in the correct place. As an aesthetic bonus, this change produces pleasing symmetry in nsHtml5Module::{Initialize,Release}Statics. Reviewed-by: Nathan Froyd <froydnj@mozilla.com>
8a28269883ab9eb995123feb521e46402d9c3e90: Bug 795418 - More tests. a=ritu
Mats Palmgren <mats@mozilla.com> - Fri, 27 Jan 2017 00:24:00 +0100 - rev 375817
Push 6996 by jlorenzo@mozilla.com at Mon, 06 Mar 2017 20:48:21 +0000
Bug 795418 - More tests. a=ritu
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip