b18cad4e3274cb2a6b92eb95779f099b79c4fd5d: Bug 1395703 - Make sure modifiedBySync CV field isn't passed to ContentProvider on updates r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Thu, 31 Aug 2017 18:05:20 -0400 - rev 378149
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
Bug 1395703 - Make sure modifiedBySync CV field isn't passed to ContentProvider on updates r=rnewman Comment from bugzilla on this ugly hack: While processing bookmarks, we sometimes need to mark them for re-upload as we're inserting new ones or updating existing ones. For example, we might set or update a dateAdded field. We perform insertions "in-bulk", and so we might be inserting some bookmarks which need to be re-uploaded, and some bookmarks which don't. We compile an array of ContentValue objects, and make a single call to our ContentProvider. This means we can't use a URI param to indicate our intent, and so a non-column field in ContentValues objects - modifiedFromSync - is set for those bookmarks which need special treatment during insertion. Bug 1392802 added a similar mechanism for updating bookmarks. However, updates are done differently - currently, we perform a single call to our ContentProvider for each bookmark. Which means we _can_ use a URI field as a signaling mechanism, which is what that patch did. However, in haste I forgot to take into consideration existing signaling mechanism, which lead to update failures. And so we're left with an even clumsier interface to our data store, with two ways to signal the same thing in different circumstances... A quick solution is to just make sure 'modifiedBySync' field never makes its way to contentprovider on updates; a more refined fix would probably modify update logic to use a ContentValues field for consistency... Either way, there's going to be something ugly, somewhere in the code. I anticipate a lot of this code changing sometime soon in order to support better transactionality of bookmark syncing, and smarter merging, and so I'm inclined to just to the simple thing for now. MozReview-Commit-ID: H10LFsqjbFY
001d66bec22f15c253e21306c72d04b518b94dd0: Bug 1395762 - Update Stylo check in file_restyling_xhr_doc.html. r=birtles
J. Ryan Stinnett <jryans@gmail.com> - Thu, 31 Aug 2017 18:57:25 -0500 - rev 378148
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
Bug 1395762 - Update Stylo check in file_restyling_xhr_doc.html. r=birtles Automation also uses env vars to change the Stylo mode, so reading the pref is not enough. Change the test to `isStyledByServo` which covers all cases. MozReview-Commit-ID: KLh42b4roF4
b28fb20723996f86bdf9c1e9e53839f82ca5c353: Bug 1383898 - Add tablet icon to Send Page to Device panel. r=markh
Edouard Oger <eoger@fastmail.com> - Tue, 29 Aug 2017 14:37:20 -0400 - rev 378147
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
Bug 1383898 - Add tablet icon to Send Page to Device panel. r=markh MozReview-Commit-ID: SqxuO1g2J0
7e5fec0ca1ca960d24daece0c62aa5634f540222: Bug 1376507 - Handle a list of contexts instead of a single context. r=billm
Blake Kaplan <mrbkap@gmail.com> - Mon, 28 Aug 2017 16:05:11 -0700 - rev 378146
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
Bug 1376507 - Handle a list of contexts instead of a single context. r=billm This might be prematurely optimized as it uses two lists (one list of active contexts and one list of inactive contexts) but I was really attracted by the idea of being able to answer questions like "is any context active" by only looking at a single context and not having to iterate the whole list every time we needed to do anything. It is really important that nobody touches any of the timestamps (or the mActive member) outside of the Watchdog lock. I thought about trying to encapsulate that data in its own class, but that felt like overkill. Let me know if you disagree. There are still a couple of uses of XPCJSContext::Get that probably need to be stamped out, but I think doing so will depend on the details of how we map JSContexts to XPCJSContext (and XPCJSRuntimes). I think that should wait for a separate bug. MozReview-Commit-ID: 9UZlh7Jutne
ded0b612dba768607ab11687d874b974a9855201: Bug 1376507 - Move state onto XPCJSContext. r=billm
Blake Kaplan <mrbkap@gmail.com> - Wed, 23 Aug 2017 17:40:09 -0700 - rev 378145
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
Bug 1376507 - Move state onto XPCJSContext. r=billm The current code assumes it can store data about "the" XPCJSContext on the WatchdogManager singleton. Once we have more than one XPCJSContext running around, that won't be possible. This moves the needed data onto the XPCJSContext itself and gives the WatchdogManager the proper context to operate on. MozReview-Commit-ID: AxyFKp9LmH3
d4cea477b7e43db13c56656b6c24f4391538544c: Backed out 2 changesets (bug 1376507) for build bustage a=backout
Wes Kocher <wkocher@mozilla.com> - Thu, 31 Aug 2017 17:08:29 -0700 - rev 378144
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
Backed out 2 changesets (bug 1376507) for build bustage a=backout Backed out changeset 266611b269cc (bug 1376507) Backed out changeset 04ecce0d1392 (bug 1376507) MozReview-Commit-ID: JC6tERhgDoS
d7cae06749f131a1fdffed1926fe526f7cfc89ee: Merge m-c to autoland, a=merge
Wes Kocher <wkocher@mozilla.com> - Thu, 31 Aug 2017 16:56:58 -0700 - rev 378143
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
Merge m-c to autoland, a=merge MozReview-Commit-ID: BlE0HFQUP9c
266611b269cc876858346826d178a1e8fef0e0d4: Bug 1376507 - Handle a list of contexts instead of a single context. r=billm
Blake Kaplan <mrbkap@gmail.com> - Mon, 28 Aug 2017 16:05:11 -0700 - rev 378142
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
Bug 1376507 - Handle a list of contexts instead of a single context. r=billm This might be prematurely optimized as it uses two lists (one list of active contexts and one list of inactive contexts) but I was really attracted by the idea of being able to answer questions like "is any context active" by only looking at a single context and not having to iterate the whole list every time we needed to do anything. It is really important that nobody touches any of the timestamps (or the mActive member) outside of the Watchdog lock. I thought about trying to encapsulate that data in its own class, but that felt like overkill. Let me know if you disagree. There are still a couple of uses of XPCJSContext::Get that probably need to be stamped out, but I think doing so will depend on the details of how we map JSContexts to XPCJSContext (and XPCJSRuntimes). I think that should wait for a separate bug. MozReview-Commit-ID: 9UZlh7Jutne
04ecce0d1392376ddc40f1dd6655bbbc90bc6a8a: Bug 1376507 - Move state onto XPCJSContext. r=billm
Blake Kaplan <mrbkap@gmail.com> - Wed, 23 Aug 2017 17:40:09 -0700 - rev 378141
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
Bug 1376507 - Move state onto XPCJSContext. r=billm The current code assumes it can store data about "the" XPCJSContext on the WatchdogManager singleton. Once we have more than one XPCJSContext running around, that won't be possible. This moves the needed data onto the XPCJSContext itself and gives the WatchdogManager the proper context to operate on. MozReview-Commit-ID: AxyFKp9LmH3
08674a4a6dc121db7cb0c28fb1512eb53da6d0ac: Bug 1395751 - Skip test_stylesheet_clone_import_rule.html with Stylo. r=manishearth
J. Ryan Stinnett <jryans@gmail.com> - Thu, 31 Aug 2017 18:20:39 -0500 - rev 378140
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
Bug 1395751 - Skip test_stylesheet_clone_import_rule.html with Stylo. r=manishearth MozReview-Commit-ID: smEHAwxRP6
3aab8b1494efb366fe048ef9eadb97d0f81ccb85: Bug 1302470 Part 6: Properly check for a frame's visibility, do not abuse isRangeVisible() for that purpose. r=mikedeboer
Mike de Boer <mdeboer@mozilla.com> - Fri, 28 Apr 2017 19:06:35 +0200 - rev 378139
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
Bug 1302470 Part 6: Properly check for a frame's visibility, do not abuse isRangeVisible() for that purpose. r=mikedeboer MozReview-Commit-ID: ErviFQrJR1u
fdd40abac61157fc28e7182a03011fbb6bb6573a: Bug 1302470 Part 5: Connect up FinderHighlighter.jsm with the new isRangeVisible function. r=mikedeboer
Mike de Boer <mdeboer@mozilla.com> - Mon, 23 Jan 2017 17:39:07 +0100 - rev 378138
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
Bug 1302470 Part 5: Connect up FinderHighlighter.jsm with the new isRangeVisible function. r=mikedeboer MozReview-Commit-ID: ABfAoZ4CBjP
a67bc2f1b62483d36ea19977718e60cb309678e6: Bug 1302470 Part 4: Change nsDisplayList::GetOpaqueRegion non-opaque lists to build up a region from its children. r=mattwoodrow
Brad Werth <bwerth@mozilla.com> - Thu, 20 Apr 2017 10:50:41 -0700 - rev 378137
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
Bug 1302470 Part 4: Change nsDisplayList::GetOpaqueRegion non-opaque lists to build up a region from its children. r=mattwoodrow MozReview-Commit-ID: LEuvazbz1X
160522290018ae5af657629dc7c2dd8b89800999: Bug 1302470 Part 3: Fix the case where HTML buttons need to generate display item children when doing opaque hit tests. r=mattwoodrow
Brad Werth <bwerth@mozilla.com> - Wed, 30 Nov 2016 14:35:37 -0800 - rev 378136
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
Bug 1302470 Part 3: Fix the case where HTML buttons need to generate display item children when doing opaque hit tests. r=mattwoodrow MozReview-Commit-ID: HwDYsnMJkM8
6b948c53394446f77cf68340671b0ba828057850: Bug 1302470 Part 2: Branch IsRangeVisible to delegate to IsRangeRendered when range is in viewport. r=masayuki
Brad Werth <bwerth@mozilla.com> - Thu, 20 Apr 2017 10:21:52 -0700 - rev 378135
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
Bug 1302470 Part 2: Branch IsRangeVisible to delegate to IsRangeRendered when range is in viewport. r=masayuki MozReview-Commit-ID: LZyvt08I9vz
399011313b3cbe01ba2c4202e524badc694c40c3: Bug 1302470 Part 1: Create a IsRangeRendered function to test range visibility in the display list. r=mstange,smaug
Brad Werth <bwerth@mozilla.com> - Fri, 24 Mar 2017 14:45:41 -0700 - rev 378134
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
Bug 1302470 Part 1: Create a IsRangeRendered function to test range visibility in the display list. r=mstange,smaug MozReview-Commit-ID: u0N73luIz7
ec6c7dd9e25fd3e09dc1222e7bcee56647ce0395: Bug 1390461 - Update langpack-webext to use WEBEXT_LANGPACKS mk flag. r=Pike
Zibi Braniecki <zbraniecki@mozilla.com> - Sun, 27 Aug 2017 17:27:19 -0700 - rev 378133
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
Bug 1390461 - Update langpack-webext to use WEBEXT_LANGPACKS mk flag. r=Pike MozReview-Commit-ID: HdfCwaDvjTa
73f1010eea4c192e73a6878751f1ce698e706e4d: Bug 1395032 - Remove remainder of the VS CRT allocator mismatch hack. r=gps
Mike Hommey <mh+mozilla@glandium.org> - Wed, 30 Aug 2017 14:06:13 +0900 - rev 378132
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
Bug 1395032 - Remove remainder of the VS CRT allocator mismatch hack. r=gps Bug 1186064 removed most of it when we started requiring VS 2015u2, but the "frex" function exported through mozglue.def.in was only used through the MSVCRT being patched by fixcrt.py, which is not done anymore. So the "frex" export is not used anymore, and so the "dumb_free_thunk" function is not used anymore as well.
1a4aac2956cf01f4280b9179cb495ac66cdf84ea: bug 1382749 - remove the "old way" of signing add-ons r=aklotz,mossop
David Keeler <dkeeler@mozilla.com> - Wed, 19 Jul 2017 13:09:46 -0700 - rev 378131
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
bug 1382749 - remove the "old way" of signing add-ons r=aklotz,mossop In particular, this removes the nsIZipReader.getSigningCert API. MozReview-Commit-ID: JPSz0pvsA5n
58f4ecda0d4ad434241d7dbe30bcf60ce261d8f7: Bug 1394975 - Remove the tabbrowser-tabbox xbl binding;r=mossop
Brian Grinstead <bgrinstead@mozilla.com> - Thu, 31 Aug 2017 09:31:36 -0700 - rev 378130
Push 94412 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:46:09 +0000
Bug 1394975 - Remove the tabbrowser-tabbox xbl binding;r=mossop This is used to change the tabs property on the tabbox, which can be done on the tabbox binding directly by passing an attribute MozReview-Commit-ID: EViFT4O4ozl
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip