This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
The reason of intermittent failure of `test_bug656379-2.html` is, synthesized
`mousemove` event coming from the parent process causes `mouseout` and
`mouseleave` events of the last synthesized `mousemove` in the test. The
reason is, synthesized `mousemove` for tests makes `PresShell` in the content
process record the cursor location, but won't make it `PresShell` in the
parent process do it. Therefore, parent process may synthesize `mousemove`
event for the system cursor position which does not match with the synthesized
mouse location in the content process. Therefore, `:hover` state may be
updated unexpectedly.
This patch makes `WidgetEvent::mFlags` have a flag to indicate whether it
came from another process. Then, makes `PresShell::HandleEvent()` ignore
synthesized `mousemove` events coming from another process only when the
recorded mouse location was set by a mouse event synthesized for tests.
Differential Revision: https://phabricator.services.mozilla.com/D65282
I think during the All Hands in Berlin you might have suggested to do this in nsPresContext::DefaultBackgroundColor,
but this seems a bit more targeted and not a header.
I haven't try tested this yet, so this more of a feedback?
Differential Revision: https://phabricator.services.mozilla.com/D63801
mHasScheduleFlush is meant to track mViewManagerFlushIsPending except mViewManagerFlushIsPending gets set to false just before we call ProcessPendingUpdates, whereas mHasScheduleFlush is set to false just after we call ProcessPendingUpdates.
There are a couple places where mViewManagerFlushIsPending gets set to false that don't clear mHasScheduleFlush though. This leaves mHasScheduleFlush true until we get another paint that changed something. This causes this code
https://searchfox.org/mozilla-central/rev/3a0a8e2762821c6afc1d235b3eb3dde63ad3b01a/layout/painting/nsDisplayList.cpp#3058
in nsDisplayList::PaintRoot to always notify of invalidation (with webrender). This in turn causes a loop in the reftest harness: notify invalidation -> mozafterpaint -> update canvas -> paint -> notify invalidation.
This code changed a bunch until settling on the current design in bug 1404091.
Differential Revision: https://phabricator.services.mozilla.com/D61738
`nsRange` instances are allocated a lot in the heap especially by editor and
spellchecker. The allocation cost is too bad for benchmarks. Therefore,
we should reuse released instances as far as possible. For managing it in
static factory methods of `nsRange`, we need to hide `nsRange` constructor.
Differential Revision: https://phabricator.services.mozilla.com/D61237
Long-pressing on a text in an unfocused iframe to select a word never
works. Currently, you need to single tap to focus the iframe first.
Each PresShell has an associated AccessibleCaretEventHub. This patch
fixes this bug by routing the event to the AccessibleCaretEventHub under
the event point, and handle it there. If the event is not handled, then
we handle it by the focused AccessibleCaretEventHub as before.
I've experimented with only routing the event to the
AccessibleCaretEventHub under the event point, without routing to the
fallback focused AccessibleCaretEventHub. However, caret dragging didn't
work in iframes. I didn't debug further.
Differential Revision: https://phabricator.services.mozilla.com/D52767
We need the resolution to be restored when and if the presshell creates
a MobileViewportManager. That decision happens in
PresShell::UpdateViewportOverridden. In order for the resolution to be
saved somewhere it has to exist outside the presshell itself, since
the presshell will be destroyed and recreated during some of the
operations that also destroy the MVM -- such as closing the devtools'
Responsive Design Mode. So Document holds this resolution and gets
accessor methods to allow the presshell to get and set that resolution
as needed.
Differential Revision: https://phabricator.services.mozilla.com/D59821
It removes a script blocker. Therefore, although it depends on the caller
whether it causes running script or not. However, we should mark it as
`MOZ_CAN_RUN_SCRIPT` for safer code.
It's called only by the destructor of `nsAutoCauseReflowNotifier`. Therefore,
this patch also marks its constructor as `MOZ_CAN_RUN_SCRIPT` for making
each creator method marked as `MOZ_CAN_RUN_SCRIPT` or
`MOZ_CAN_RUN_SCRIPT_BOUNDARY`.
Most of the creators is mutation listener methods. However, `PresShell`
does nothing after destroying `nsAutoCauseReflowNotifier`. Therefore,
this patch does not change the callers in MutationObserver.cpp to use
`RefPtr<PresShell>` at calling them because changing it may cause performance
regression.
Perhaps, we should create another methods of `WillCauseReflow()` and
`DidCauseReflow()` to avoid unnecessary `MOZ_CAN_RUN_SCRIPT` marking.
However, I'm not sure whether most callers may run script or not because
of outside of my knowledge.
Differential Revision: https://phabricator.services.mozilla.com/D55805
Long-pressing on a text in an unfocused iframe to select a word never
works. Currently, you need to single tap to focus the iframe first.
Each PresShell has an associated AccessibleCaretEventHub. This patch
fixes this bug by routing the event to the AccessibleCaretEventHub under
the event point, and handle it there. If the event is not handled, then
we handle it by the focused AccessibleCaretEventHub as before.
I've experimented with only routing the event to the
AccessibleCaretEventHub under the event point, without routing to the
fallback focused AccessibleCaretEventHub. However, caret dragging didn't
work in iframes. I didn't debug further.
Differential Revision: https://phabricator.services.mozilla.com/D52767
There is no way this ever properly worked, as we always passed null for
`aFrameState`.
So it'd only work if we reframed the document element or such... Which is not
amazing.
For simpler test-cases, when we don't construct the scrollframe via
PresShell::Initialize, but via the regular frame constructor updates
(ContentAppended, etc...), those end up working because we go through lazy frame
construction, which ends up in RecreateFramesForContent, which passes
mTempFrameTreeState.
Differential Revision: https://phabricator.services.mozilla.com/D59569
On webrender on android, parent-process pages (eg about:support) were not being
rendered immediately after minimising then resuming the app, resulting in a
black screen. The problem was that webrender believed the previous frame was
still valid, and therefore that it did not need to render a new
one. Content-process pages were unnaffected because we clear cached resources
when the app is minimised, so we accidentally rendered a new frame on
resumption.
To fix this we always force a new frame to be rendered immediately on
resumption. This uncovers a race condition which causes us to sometimes render
frames at the wrong size when the window size has changed (for example when
showing or hiding the keyboard), so that is also fixed.
This also fixes a bug affecting fenix, where when opening a page in a new tab
the portion of the screen where the keyboard used to be would remain black until
the page had loaded. This no longer occurs because we force a composite as soon
as the keyboard is hidden.
Additionally, this patch reverts the original attempt at fixing this
bug, as it is not necessary.
Differential Revision: https://phabricator.services.mozilla.com/D59367
