Bug 1257326 - Respect origins set by any caller of CommandLineHelper.add. Origins will be set for any caller of CommandLineHelper.add, but will only be propagated if args are added to extra_args. This results in an incorrect origin recorded for mozconfig injected arguments. MozReview-Commit-ID: 9mJCaNHyd5C

Bug 1269034 - Fix getSuggestionForQuery in inspector actor for id queries. r=bgrins Make sure that result node id is not empty before appending it to the results MozReview-Commit-ID: 5SuTrNf4t8v

Bug 1261527 - Long-press on smartfolder. r=sebastian MozReview-Commit-ID: JPkELM3mtWW

Bug 1245493 - Don't animate when showing toolbar when FF is first unhidden. r=margaret After this patch, I still occasionally see the toolbar positioned part way down from the top of the screen. However, this state looks slightly less janky without the animation I removed and I can't consistently reproduce it anymore. Given the DynamicToolbar.setVisible calls I make, I'd guess this is likely to be a bug caused by BrowserApp.onTabChanged (and thus DynamicToolbar.setVisible) not getting called instantly and so the DynamicToolbar is initialized to a different location on screen. I'd guess it's a bug in DynamicToolbar as to why it's positioned partially off-screen. There is a little bit of code duplication, but that is because the code to load a url on a new intent is duplicated (i.e. once from GeckoApp.initialize - the initial load - and once from GeckoApp.onNewIntent). This could potentially be cleaned up if we moved the app loading code into onResume, but that may not be possible since we need to wait for Gecko to start up. Alternative solution: show the toolbar each time onStart is called (i.e. FF is unhidden). This is good for the user - they'll be more aware which page they're on - but it's janky with the current implementation, where the page content does not scroll when the toolbar is shown so previously visible content is hidden. Thus, I went with the other approach. fwiw, Chrome does this behavior, but scrolls the toolbar offscreen shortly after it is shown. MozReview-Commit-ID: 7JjCrIf4KTm

Bug 1245493 - Add comments to existing code to clarify them. r=margaret MozReview-Commit-ID: KwOy1KMoPaY

Bug 1243585 - Move ping builders -> pingbuilders/. r=sebastian This overwrites a commit I did at the beginning, but fixing the version control would have been a waste of time. MozReview-Commit-ID: Ry9WRpTf8s

Bug 1243585 - Move ping builders -> pingbuilders/. r=sebastian This overwrites a commit I did at the beginning, but fixing the version control would have been a waste of time. MozReview-Commit-ID: Ry9WRpTf8s

Bug 1243585 - Stop IntentService if there is a connection failure. r=sebastian I would have folded this but I screwed up but the version control is getting messy. MozReview-Commit-ID: 3LaYkrao4dD

Bug 1243585 - Add short-circuits when there are no pings. r=sebastian Ideally, we'd just not run the service but skimming, I see no clean way to do that with the existing code. MozReview-Commit-ID: HRU1PAmYoil

Bug 1266995 - Remove XPIDL_MODULE from moz.build; r?glandium We previously changed it to do nothing. This gets rid of usages in moz.build files and support for the variable in the sandbox. As part of making this change, I noticed that several moz.build files (notably under dom/) now only contain XPIDL_SOURCES variables. We could probably aggressively consolidate these moz.build files together if we wanted. MozReview-Commit-ID: JExXITohgvU

Bug 1266995 - Derive XPIDL module name from relative source directory; r?glandium XPIDL module names aren't actually relevant because at the end of the day an XPCOM manifest loads an XPT file and the name of the loaded file doesn't really have any impact on run-time behavior: it's the content in the XPT that matters. Furthermore, we re-link the various intermediate XPT files into a single interfaces.xpt, which is shipped as part of omni.ja. So the XPIDL module names don't survive to a shipping Firefox. Again, only the content in the XPT matters. This commit changes the build system to derive the intermediate XPT/"module" names from relative directory paths. A future commit will remove remaining references of XPIDL_MODULE from the tree. We keep the commits separate to make review easier. For XPIDL files we ship in Firefox, this change "just works." However, there are some test-only XPT files that now have new names. So we had to adjust references to those paths in various locations. This change should not require a clobber because chrome.manifest in local builds loads the "interfaces.manifest" file which is rewritten by config/makefiles/xpidl/Makefile to contain only the list of active .xpt files. If we used the traditional "add entry to manifest" method, this would orphan old .xpt paths/entries and could lead to issues. MozReview-Commit-ID: B97xKHxzv9e

Bug 1266995 - Use unique XPIDL_MODULE for each moz.build; r?glandium There were a few moz.build files specifying the same XPIDL_MODULE value. Probably the craziest was timermanager's, which specified the "update" module! In preparation for making the xpt filename derived from the relative source directory, we make all XPIDL_MODULE values unique so each directory has its own xpt. This will make automatic conversion of package-manifest.in easier. MozReview-Commit-ID: 5nVgsccm3Zi

Bug 1266995 - Use DIST_SUBDIR instead of XPIDL_MODULE in export test; r?glandium We're about to remove XPIDL_MODULE. Switch to a more appropriate variable. MozReview-Commit-ID: 5FU6vcJQM8w

Bug 1268197 - add exception to startup IO test for webcompat system add-on r=jmaher a=merge MozReview-Commit-ID: DQ9ndBpRUvt

Jimmy had a horrible rebasing accident. Reattach poor Jimmy's arm. (followup for bug 1171632) a=merge MozReview-Commit-ID: 6fNsUPqNduo

Merge inbound to m-c a=merge MozReview-Commit-ID: BKbqwBtHrBR

Bug 1265112 - When rendering blend modes with CompositorOGL, use NV_texture_barrier (if available) to sample directly from the framebuffer. r?jrmuizel MozReview-Commit-ID: fWSgFOTmhS

Bug 1265112 - Add support for NV_texture_barrier to GLContext. r?jrmuizel MozReview-Commit-ID: 95j0YBKN1P1

Bug 550426 - Update test to expect the new background-position-x/-y properties. MozReview-Commit-ID: 5pceyVeF15N

Bug 550426 - Add a few reftests for background-position-x/-y. r=dbaron MozReview-Commit-ID: 7SoQqnS46A9