This change utilizes components.conf to distinguish between the contract implementations of nsISessionStoreFunctions per platform.
Differential Revision: https://phabricator.services.mozilla.com/D206904
These properties were previously being checked much later, during xptcodegen,
and causing methods to be treated as noscript implicitly.
This change enforces the noscript requirements earlier when possible in
xpidl.py, to produce better errors, and adds addiitonal checks to ensure that
types which need to be builtinclass are marked as such.
This required some changes to interfaces in order to satisfy the new checks.
Differential Revision: https://phabricator.services.mozilla.com/D207804
Previously the `boolean` type was also declared using a `bool` typedef in
xpidl, meaning that both were used in various places. This patch standardizes
on the built-in `boolean` type, removing the typedef.
Differential Revision: https://phabricator.services.mozilla.com/D206382
- Create a local page we will access via an about: URL
- In that page, demonstrate how to do some stuff, then fire a custom event
indicating its stuff is done _and_ return complex data in that event.
console.log() didn't seem to be visible in the HiddenWindow, so I also
piped out debug strings for development purposes, so they can be
console.logged in the Service, where we can see them.
- Instead of listening for DOMContentLoaded/pageshow, instead listen for
the new CustomEvent.
- In UserCharacteristicsPageService, receive the data from the page and
populate the appropriate Glean metrics
- Refactor the calling of nsUserCharacteristics::PopulateData() and
SubmitPing(). Now we call PopulateDataAndEventuallySubmit() which will
eventually call SubmitPing after our promise is resolved.
- To make it a little cleaner (so ContentPageStuff() isn't calling
SubmitPing()) we return the promise out of ContentPageStuff() that
PopulateDataAndEventuallySubmit() will await and then call SubmitPing()
when that promise resolves
Differential Revision: https://phabricator.services.mozilla.com/D203055
After bug 306344 this is the last remaining incompatibility with
<marquee>. I think we should be able to drop it. Use counters for
"finish" are relatively high (>0.1%), but I'm pretty sure that's because
that event name is shared with web animations. "bounce" is a more
realistic measure, and that's 0.003%, which is more expected.
Differential Revision: https://phabricator.services.mozilla.com/D206387
In particular:
* Always handle meta viewport in RDM. This fixes bug 1625999 too by
making touch simulation enabled and disabled consistent.
* Restore the resolution to 1 when toggling RDM. This is just simpler,
and we're not keeping around the visual viewport offsets anyways
so...
* Deal with the change more easily, at the same point we switch
scrollbars etc.
Differential Revision: https://phabricator.services.mozilla.com/D206266
We also simplify the tooltip text provider loop, and make it work better
now that e.g. the anonymous button in file inputs can be targeted.
Differential Revision: https://phabricator.services.mozilla.com/D203759
We don't want to start skipping entries just because callers passed in
aRequireUserInteraction, since the feature is not ready and the flag in the
entries might not be correct.
Differential Revision: https://phabricator.services.mozilla.com/D203376
If session history in the parent is enabled then session store only works
correctly if the platform collection code is turned on.
Differential Revision: https://phabricator.services.mozilla.com/D203375
These prefs don't do anything unless browser.sessionstore.platform_collection is
enabled, but we don't need the granularity that they provide. Let's just use
have the one browser.sessionstore.platform_collection pref control everything.
Differential Revision: https://phabricator.services.mozilla.com/D203374
This patch modifies the behaviour of loads when the DONT_RETARGET
nsIURILoader flag is set, making them ignore the Content-Disposition
header. This means that loads which cannot trigger downloads will
attempt to display handleable content which would otherwise be
downloaded.
This keeps overall behaviour of object/embed elements more similar to
their behaviour pre-Fission, while allowing them to load attachment PDFs
and Images as-if they were being displayed by a plugin.
This patch does not change the existing behaviour around
unknown/unhandleable resource types in object/embed elements.
In Gecko, object/embed elements are prevented from triggering downloads
or external protocol handlers during their initial load. Other browser
engines can trigger a download for an unknown resource type (or
sometimes an attachment resource).
The new pref dom.navigation.object_embed.allow_retargeting can be
enabled to instead trigger a download when loading these resources
within an object/embed element.
Differential Revision: https://phabricator.services.mozilla.com/D201645
We also simplify the tooltip text provider loop, and make it work better
now that e.g. the anonymous button in file inputs can be targeted.
Differential Revision: https://phabricator.services.mozilla.com/D203759
This changes comes with several different refactorings all rolled into one,
unfotunately I couldn't find a way to pull them apart:
- First of all annotations now can either recorded (that is, we copy the value
and have the crash reporting code own the copy) or registered. Several
annotations are changed to use this functionality so that we don't need to
update them as their value change.
- The code in the exception handler is modified to read the annotations from
the mozannotation_client crate. This has the unfortunate side-effect that
we need three different bits of code to serialize them: one for annotations
read from a child process, one for reading annotations from the main process
outside of the exception handler and one for reading annotations from the
main process within the exception handler. As we move to fully
out-of-process crash reporting the last two methods will go away.
- The mozannotation_client crate now doesn't record annotation types anymore.
I realized as I was working on this that storing types at runtime has two
issues: the first one is that buggy code might change the type of an
annotation (that is record it under two different types at two different
moments), the second issue is that types might become corrupt during a
crash, so better enforce them at annotation-writing time. The end result is
that the mozannotation_* crates now only store byte buffers, track the
format the data is stored in (null-terminated string, fixed size buffer,
etc...) but not the type of data each annotation is supposed to contain.
- Which brings us to the next change: concrete types for annotations are now
enforced when they're written out. If an annotation doesn't match the
expected type it's skipped. Storing an annotation with the wrong type will
also trigger an assertion in debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D195248
Emilio Cobos Álvarez
kycn
Nika Layzell
Paul Zuehlcke
Yi Xiong Wong
Norisz Fay
Sandor Molnar
Greg Stoll
Stanca Serban
Tom Ritter
Peter Van der Beken
aiunusov
Gijs Kruitbosch
Thomas Wisniewski
mcheang
Daisuke Akatsuka
Natalia Csoregi
Joel Maher
Gabriele Svelto
Dave Townsend
Cristian Tuns
Malte Juergens