We need to clamp accumulations to fit in our data representation (int). This
patch records the number of times, and for which probes, we had to do so.
MozReview-Commit-ID: GSs3oFvLKlL
--HG--
extra : rebase_source : 03aff1b8b645a7934ecbf51a1c2a66cc63dd29f4
Internally Histograms use int, which is signed.
Our API uses uint32_t, which is not.
Our JS API uses ToUint32, which takes provided values modulo UINT32_MAX.
This patch consolidates behaviour so that all values greater than INT_MAX will
be correctly recorded in the highest bucket of a Histogram... instead of
having values between INT_MAX and UINT32_MAX end up as 0s, and values above
UINT32_MAX being taken modulo UINT32_MAX, but only from the JS API.
MozReview-Commit-ID: CzaaNZkPEji
--HG--
extra : rebase_source : fe3450fc5cb81d015f53325819e2726e7af2a6f7
URL queries don't need to return queries not shortcuts, as that isn't what the invoker is expecting.
MozReview-Commit-ID: 74LvXqc40Ps
--HG--
extra : rebase_source : d25b78fb73d9319989a52b30b4439ccdd1f999b1
Looks like that any script of web pages don't run in reader mode. If so,
it's safe narrate module to listen to keydown events of non-printable keys
because nobody listens to following keypress events of them. So, it's OK
to stop dispatching following keypress event of keys handled by keydown
event handlers of narrate module.
MozReview-Commit-ID: Agn8H8j8opz
--HG--
extra : rebase_source : 6d609936ce2592e9d23b100e3b875bd115b74c47
It would be convenient to get nsPresContext from nsIDocument.
MozReview-Commit-ID: Ei6V3UE8XGr
--HG--
extra : rebase_source : 8d2a917eb62cf341e4e1810451fd01c01dbc3bad
Note that this patch also replaces legacy VK_* with KEY_*, and replaces
synthesizeKey() for inputting some characters with sendString() because
it's better and clearer what it does and it sets shiftKey state properly.
MozReview-Commit-ID: De4enbjux3T
--HG--
extra : rebase_source : 2296b84bff8e22f01eeb48cd8614fac5db11136a
Puts Remote (Synced) Tab matches before other history results.
Changes deduping algorithm to replace simple history matches with tab matches when the url is the same.
Keeps overriding a Remote Tab with a Local Tab when the url is the same.
MozReview-Commit-ID: 76urDklKtRF
--HG--
extra : rebase_source : f5d37af3d0c0714e0f33b5548c4bb3b90519543b
Along with removing the view source standalone windows and prefs this patch:
1) Re-structures several of the view source tests that were only testing the old
standalone windows to now test view source in tab.
2) Adds support viewSourceUtils.viewSource() to open a browser window when there
aren't any open (for browser toolbox view source).
3) Cleans up some of the API for viewSourceUtils and removes the old deprecated
ways of calling it.
MozReview-Commit-ID: DI6sgZwbCf
--HG--
extra : rebase_source : 64677186122f74ab95912d5f3f173cf37472458a
The behavior that this test expects is not the same as when viewing
source in a browser tab.
MozReview-Commit-ID: EwzrCz0VCJY
--HG--
extra : rebase_source : 6e4f994d86527e6608088fb84c1be8870be3c62e
Removed the code for app.update.test.loop from updates.js which hasn't been used in years
Removed the no longer needed Cc, Ci, etc. constants from the xpcshell and mochitest-chrome common test files.
The default styles of richlistbox autocomplete were originally created to support the location bar popup, but now every autocomplete field uses the richlistbox version. This reworks the styles so that the number of overrides is minimized.
MozReview-Commit-ID: BwagKpMR5Dt
--HG--
extra : rebase_source : 52eda7f9d561dd23f279a3d15659e84f6c46eec6
Disk corruption can lead to the stored length of a value to be
unreasonably large and trigger an OOM.
Since values are all currently <= 32 bytes, we can safely enforce
a 256-byte upper bound.
MozReview-Commit-ID: XygReOpEK3
--HG--
extra : rebase_source : cd2bc880d43612b04d43fb4132bba32bdc3d0f3e
While we could not cut the order of the inputs over directly to the AddToHash methods
(because AddToHash(string) does not exist) - we could rearrange them and then not need
to build a temporary string.
MozReview-Commit-ID: 6At4MQ0KotE
--HG--
extra : rebase_source : d768a38a726e4f459175d2f62e7f60ba4c1c54ef
The autocomplete module listens to keypress event for both printable keys and
non-printable keys a lot. However, we'll stop dispatching keypress event for
non-printable keys in the default event group of web content. So, autocomplete
should listen to keypress events at the system event group.
Note that it's difficult to change keypress event listeners to keydown event
listeners because if we stop keypress events at preceding keydown event in
autocomplete or satchel module, some other modules fail to handle keydown or
keypress event before autocomplete and it's not easy to investigate which
module's which keypress event listener should be changed to keydown event
listener. Therefore, this patch doesn't do it at least for now.
MozReview-Commit-ID: 7e3aklmKrXu
--HG--
extra : rebase_source : 1a1e71972e4f56f088c0372e12961ffb683c7b26
The change to RootAccessible.cpp fixes an obvious bug introduced in bug 741707.
The visibility changes in gfx/thebes are because NS_DECL_ISUPPORTS has a
trailing "public:" that those classes were relying on to have public
constructors.
MozReview-Commit-ID: IeB8KIJCGhU
See the comment on "Address test failures caused by bumping timer precision to 2 ms"
for more details.
MozReview-Commit-ID: LrsucEPdZIo
--HG--
extra : rebase_source : 8147c034f7dc93f678eebc80b0afabf55729d804
This patch creates the capability to have callsites specify if timestamps
should be clamped only in Resist Fingerprinting Mode, or in the more expansive
Timer PRecision Reduction Mode.
Then it changes the CSS Animation callsite to only apply in RFP Mode.
This avoids regressing RFP.
MozReview-Commit-ID: B1pSri0kRk6
--HG--
extra : rebase_source : f3d8c1f9561fbb19d1ca8594ba2b69cffd25445b
Summary:
These are made persistent:
1. What questions will you answer with this data?
These probes are critical to understanding use of notifications and push in
general (push provides significant incentive to sites to use notifications, so
the two are highly correlated). These probes allow us to understand when push
is enabled, and when pushes are propagated.
2. Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements? Some example responses:
These allow is to understand baseline platform characteristics and ensure that changes don't degrade experience.
3. What alternative methods did you consider to answer these questions? Why were they not sufficient?
We have telemetry on autopush (our server infrastructure), and the information we get there is in many ways superior to data collected through the browser, but these metrics are impossible to measure using autopush.
4. Can current instrumentation answer these questions?
See 3.
5. List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories on the found on the Mozilla wiki.
Measurement Description Data Collection Category Tracking Bug #
WEB_NOTIFICATION_CLICKED 2 1429286
WEB_NOTIFICATION_PERMISSIONS 2 1429286
WEB_NOTIFICATION_SHOWN 2 1429286
PUSH_API_NOTIFY 2 1429286
6. How long will this data be collected? Choose one of the following:
I want to permanently monitor this data. (Martin Thomson, :mt)
7. What populations will you measure?
All channels, countries, and locales. No filtering is in place. These are all opt-out telemetry.
8. Please provide a general description of how you will analyze this data.
Changes are monitored for changes, or analyzed on demand.
I believe that there are telemetry alerts that trigger on significant changes. If there isn't, there should be.
9. Where do you intend to share the results of your analysis?
telemetry.m.o, w3c webapps
Bug #: 1429286
Differential Revision: https://phabricator.services.mozilla.com/D361
MozReview-Commit-ID: Kkc1Qr6UaJ8
This macro is identical to NS_INTERFACE_MAP_END and encourages the
reader to think that there's something extra-special threadsafe about QI
implementations that use the macro, when in reality there's nothing of
the sort.
The only purpose of these bindings was to insert a stylesheet, which has been
moved to be included in toolkit/content/components.css.
MozReview-Commit-ID: 23jqkIrbVvi
--HG--
extra : rebase_source : 8d13f7a8afa730207d40e1457e36ec51331c4ea7
The titles for the root bookmark folders in the database will now never get updated. This
avoids doing maintenance and changing them if the locale changes.
The UI is now responsible for displaying the correct title.
WebExtensions API will get the UI visible names.
MozReview-Commit-ID: ErPPJXxy2d3
--HG--
extra : rebase_source : f08caa5b0d00ae81ffabf4a1076bd56b66414418
Christoph Kerschbaumer
Brian Grinstead
Gurzau Raul
Jonathan Kingston
Chris H-C
Mark Banner
Masayuki Nakano
Hiroyuki Ikezoe
Jared Wein
shindli
Connor Masini
Kit Cambridge
Cosmin Sabou
Sebastian Hengst
Kris Maglione
Oriol Brufau
Andreea Pavel
Marco Bonardo
Richard Marti
Dorel Luca
vinoth
Narcis Beleuzu
Margareta Eliza Balazs
Chris Peterson
Brendan Dahl
David Major
Noemi Erli
Robert Strong
Shane Caraveo
Paolo Amadini
Coroiu Cristina
Tim Nguyen
Kirk Steuber
Francois Marier
Daniel Stenberg
Jeff Walden
Apoorv Goel
Kartikaya Gupta
Tom Ritter
Dão Gottwald
Alejandro Rodriguez
Andrea Marchesini
Boris Zbarsky
Ciure Andrei
Franziskus Kiefer
David Anderson
Martin Thomson
Nathan Froyd
Mark Striemer
Martin Stransky
Timothy Guan-tin Chien
Emilio Cobos Álvarez