PhysicalSocketServer isn't currently used by Mozilla's WebRTC
integration, but just in case, let's make sure that this array index is
bounds-checked in actual use, not just in debug builds (which tend to
never see realistic test conditions).
Differential Revision: https://phabricator.services.mozilla.com/D52745
--HG--
extra : moz-landing-system : lando
These are single-fd polls of the X server socket, which in practice will
be much smaller than FD_SETSIZE, but it's cleaner to just not have the
fixed-size array in the first place.
Differential Revision: https://phabricator.services.mozilla.com/D52744
--HG--
extra : moz-landing-system : lando
Microsoft IME on Windows 10 20H1 (build 19025+) supports IME private mode by
input scope. Although previous Windows version uses undocumented API for
Edge and IE only, next Windows will use public API for it.
So let's use IS_PRIVATE input scope in private browsing mode.
Depends on D53917
Differential Revision: https://phabricator.services.mozilla.com/D53918
--HG--
extra : moz-landing-system : lando
This is a regression by bug 1568996. Although editor uses nsFrameSelection to
move caret, if frame is dirty, nsFrameSelection returns error.
So by bug 1568996, we flush layout before calling nsFrameSelection. But we
should stop flushing layout when we don't use nsFrameSelection.
Differential Revision: https://phabricator.services.mozilla.com/D53919
--HG--
extra : moz-landing-system : lando
Detect if Unix utilities on win32 are being picked up from a foreign
installation of MinGW, such as the tools packaged with Git for Windows.
If autoconf dies during `./mach configure` and foreign tools are found
in $PATH then warn the user that their $PATH may need to change to fix
the problem.
Differential Revision: https://phabricator.services.mozilla.com/D52960
--HG--
extra : moz-landing-system : lando
This expands Element with chrome-only setAttribute methods that give devtools
callers an ExtendedPrincipal with a CSP with a flag set to allow changes to
inline styles. This gives devtools the ability to modify documents with a
Content-Security-Policy.
Differential Revision: https://phabricator.services.mozilla.com/D41313
--HG--
extra : moz-landing-system : lando
The previous patch writes the registry value correctly, but the Firefox
InstallerPrefs module deletes it during startup because it's in the
same key where the actual pref values go and the module unconditionally
deletes every value there. So making it only delete values that are
recognizably actual prefs should fix this.
Differential Revision: https://phabricator.services.mozilla.com/D53693
--HG--
extra : moz-landing-system : lando
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
