FxA/Sync stores a credential in login storage but this is no longer user-facing so users shouldn't expect it to be cleared. Users can still diconnect Sync properly from about:preferences.
Differential Revision: https://phabricator.services.mozilla.com/D53834
--HG--
extra : moz-landing-system : lando
We shouldn't hide data saved by legacy extensions, the user should remain in control of them since they may contain credentials they want to delete.
Differential Revision: https://phabricator.services.mozilla.com/D53833
--HG--
extra : moz-landing-system : lando
I mistakenly attempted to `import urllib.urlparse` instead of `urllib.parse`, which caused a bunch of tests running under python3.5 tox to be blocked on this.
This correction allows tox on python3.5 to run all 167 tests, allowing me to cross-check further python3 conversion work.
Differential Revision: https://phabricator.services.mozilla.com/D54041
--HG--
extra : moz-landing-system : lando
Previously, we created TextureD3D11 objects in the content process to back surfaces created for the plugin process. Those objects were then composited by the async ImageBridge. In order to remove Win32 kernel operations from content (including DX/GDI operations), this patch bounces the requests from content to the compositor process. The compositor process maintains 2 textures to be used for all plugin composition -- one for the plugin process and one for display. The plugin process can freely write to its texture and request composition when it is done, which triggers a blit to the display texture. This mirrors pre-existing behavior.
Differential Revision: https://phabricator.services.mozilla.com/D46086
--HG--
extra : moz-landing-system : lando
SurfaceDescriptorGPUVideo, which currently only represents RemoteDecoder video, switches from being a struct to a union that holds a SurfaceDescriptorRemoteDecoder struct. SurfaceDescriptorRemoteDecoder is a new name for the old SurfceDescriptorGPUVideo. This is done so that we can later add SurfaceDescriptorPlugin as another type of SurfaceDescriptorGPUVideo.
Differential Revision: https://phabricator.services.mozilla.com/D52400
--HG--
extra : moz-landing-system : lando
IGPUVideoSurfaceManager is an interface that the ImageBridgeChild uses to perform GPUVideoImage operations. RemoteDecoderManagerChild is one. We define another for plugins later in this patch series.
Differential Revision: https://phabricator.services.mozilla.com/D52397
--HG--
extra : moz-landing-system : lando
In anticipation of the rest of this patch series, we make 2 changes to the RemoteDecoderManager:
1. Rename RemoteDecoderManagerChild::DeallocateSurfaceDescriptorGPUVideo to DeallocateSurfaceDescriptor
2. Move call to RemoteDecoderManager::GetSource() from GPUVideoTextureClient to RemoteVideoDecoder.
Differential Revision: https://phabricator.services.mozilla.com/D52396
--HG--
extra : moz-landing-system : lando
These operations report whether certain async plugin drawing modes are supported on the host architecture. They use kernel graphics operations to decide this so they need to be removed from the content process for sandboxing. We just bounce the requests to the gpu process (or main process on systems without a GPU process).
Differential Revision: https://phabricator.services.mozilla.com/D46085
--HG--
extra : moz-landing-system : lando
Use this pref to disable NPDrawingModelAsyncWindowsDXGISurface mode, which will force compatible plugins (Flash) to use NPDrawingModelAsyncBitmapSurface.
Differential Revision: https://phabricator.services.mozilla.com/D46084
--HG--
extra : moz-landing-system : lando
This fallback drawing mode primarily uses in-memory textures in the content process (via Readback) but uses gfxPlatform to establish the GPU texture type. On Windows, this is always Win32 so we can avoid the gfxPlatform call (which uses Win32k heavily). I believe that this removes all Win32 operations involved in this drawing mode in a content process.
Differential Revision: https://phabricator.services.mozilla.com/D46083
--HG--
extra : moz-landing-system : lando
This patch fixes a minor issue with manifestparser when it is used in python 3. The problem was that dict.items() returns a generator in python 3 instead of a list.
Differential Revision: https://phabricator.services.mozilla.com/D53953
--HG--
extra : moz-landing-system : lando
There are frequent shutdown hangs in this directory. Making us reuse
content processes when Fission is enabled has papered over the
shutdown hangs from reader mode tests in other directories, so
hopefully it will help here, too.
Differential Revision: https://phabricator.services.mozilla.com/D54012
--HG--
extra : moz-landing-system : lando
This turns off the telemetry to Tiles in m-c. Activity Stream related telemetry to Tiles will be handled separately.
Differential Revision: https://phabricator.services.mozilla.com/D53875
--HG--
extra : moz-landing-system : lando
In short - if a user forcibly terminates the browser because it seems
to be permanently hung, we currently do not get a change to record the
hang. This is unfortunate, because these likely represent the most
egregious hangs in terms of user frustration. This patch seeks to
address that.
If a hang exceeds 8192ms (the current definition of a "permahang" in
existing BHR terms), then we decide to immediately persist it to disk,
in case we never get a chance to return to the main thread and
submit it. On the next start of the browser, we read the file from
disk on a background thread, and just submit it using the normal
mechanism.
Regarding the handling of the file itself, I tried to do the simplest
thing I could - as far as I can tell there is no standard simple
serialization mechanism available directly to C++ in Gecko, so I just
serialized it by hand. I didn't take any special care with endianness
or anything as I can't think of a situation in which we really care
at all about these files being transferable between architectures. I
directly used PR_Write / PR_Read instead of doing something fancy
like memory mapping the file, because I don't think performance is a
critical concern here and it offers a simple protection against
reading out of bounds.
Differential Revision: https://phabricator.services.mozilla.com/D52566
--HG--
extra : moz-landing-system : lando
This patch bascially changes the test to use the SpecialPowers.spwan()
instead of the ContentTask.spawn(). It also adds code to ensure the
content proces is shut down entirely while it involves workers in the
test. Because it would have a timing issue if we reopen a page which
used a worker before immediately after it has been closed.
Differential Revision: https://phabricator.services.mozilla.com/D53788
--HG--
extra : moz-landing-system : lando
Note that the `stackPointer == 0` assertion would crash anyway, so this
shouldn't add crashes. But it should make these new crashes appear separate,
making them hopefully easier to find and analyze.
Differential Revision: https://phabricator.services.mozilla.com/D52524
--HG--
extra : moz-landing-system : lando
When the profiler shuts down, it destroys all remaining `RegisteredThread`'s,
including the embedded ProfilingStack that stores labels for each thread.
Now, it is possible that some threads may outlive the profiler (e.g., Rayon
threads, which cannot be synchronously shut down), so there could be labels left
when the `ProfilingStack` gets destroyed, which triggers the `stackPointer == 0`
assertion in the destructor.
Removing the assertion would not be enough, because after that, the thread may
still try to pop labels (using a pointer to the now-destroyed `ProfilingStack`
stored in `AutoProfilerLabel`), causing a UAF.
`AutoProfilerLabel` could theoretically check that the profiler is still alive
before trying to pop labels, but that would add a significant cost every time
the `ProfilingStack` is accessed, because the profiler mutex would need to be
locked.
The solution here is to make `ProfilingStack` a separate heap object, owned
both by the profiler through the thread's `RegisteredThread`, and by the thread
itself through the thread-local `sProfilingStackOwnerTLS`.
The first owning link is severed when the profiler shuts down.
The other owning link is severed when the thread unregisters itself (before or
after shutdown).
This way the `ProfilingStack` stays alive as long as needed by the thread, even
if it outlives the profiler.
Implementation detail: `ProfilingStack` is used in other places as a straight
object, so it cannot be made ref-counted itself. Instead we use
`ProfilingStackOwner`, a small ref-counted shell around it.
Differential Revision: https://phabricator.services.mozilla.com/D49141
--HG--
extra : moz-landing-system : lando
OpenCommon now removes the root content object, so those parts of the big
comment don't look relevant anymore. And tests pass with this change...
I _think_ this does not reintroduce bug 253951, but I'm not 100% how to check.
Differential Revision: https://phabricator.services.mozilla.com/D52602
--HG--
extra : moz-landing-system : lando
Instead of trying to understand the precise Control Flow Graph, we now construct
MIR more like how a baseline compiler does it: whenever we have a forward jump
in the bytecode we add the block to a pendingBlocks list (keyed on the target
pc) and when we get to a jump target op we "link" any pending blocks for that
pc.
This patch also changes 'continues' in while/for-in/for-of loops to be more
similar to continues in for-loops and do-while loops. They're now just forward
jumps to the end of the loop body, instead of backward jumps to the branch at
the top that jumps to the condition. It's simpler and because they're now plain
forward branches the PendingBlock system handles them automatically.
We still always emit a jump target op for continues, even if there are no
continues. It's pretty easy to optimize this but that will be done in a
follow-up (bug 1595699) to not complicate this patch more. We can likely also
remove some source notes.
Differential Revision: https://phabricator.services.mozilla.com/D52635
--HG--
extra : moz-landing-system : lando