Moved mozilla::WidgetMosueEventBase::buttonType in MouseEvents.h to mozilla::MouseButton in EventForwards.h, and mozilla::WidgetMouseEventBase::buttonsFlag to mozilla::MouseButtonsFlag so that any referer in header files do not need to include MouseEvents.h only for referring them. Instead, they just need to include EventForwards.h. Now when MouseEvents.h is changed, the rebuild speed becomes faster.
Differential Revision: https://phabricator.services.mozilla.com/D25325
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::inputSource to WidgetMouseEventBase::mInputSource
Differential Revision: https://phabricator.services.mozilla.com/D25322
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::pressure to WidgetMouseEventBase::mPressure
Differential Revision: https://phabricator.services.mozilla.com/D25314
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::button to WidgetMouseEventBase::mButton.
Differential Revision: https://phabricator.services.mozilla.com/D25309
--HG--
extra : moz-landing-system : lando
Renamed all class member instances from WidgetMouseEventBase::buttons to WidgetMouseEventBase::mButtons
Differential Revision: https://phabricator.services.mozilla.com/D25297
--HG--
extra : moz-landing-system : lando
This patch makes `nsViewManager::GetPresShell()` and
`nsIWidgetListener::GetPresShell()` (overridden by `nsView` and
`nsWebShellWindow::WidgetListenerDelegate`) return `mozilla::PresShell*`.
Additionally, makes `nsWebShellWindow::GetPresShell()` also return
`mozilla::PresShell()`.
Differential Revision: https://phabricator.services.mozilla.com/D26454
--HG--
extra : moz-landing-system : lando
`nsChildView::GetEditorView()` is called by `TextInputHandlerBase::GetWindowLevel()`
which is called when Cocoa requests window level of focused widget.
It currently gets widget including focused element (e.g., it may be in a XUL
`<panel>`) with `eQueryTextContent` event. However, it requires only the widget
(i.e., when a XUL `<panel>` has focused element, the widget for the panel).
Therefore, it does not require to flush the layout.
However, on macOS, `ContentEventHandler` always flushes layout even with
`eQueryContentState` which does not require any layout information. Whether
it requires flushing layout or not is considered with
`WidgetQueryContentEvent::mNeedsToFlushLayout` but this is set to false only
when `IMEContentObserver` notifies widget (and IME) of focus set. At this
time, only on macOS, IME caches the layout information, for example, the
character coordinates, but we don't have a way to update it. This is the reason
why we always flush layout on macOS.
Unfortunately, when a menu popup frame is created, widget for the popup is
created synchronously. Then, Cocoa retrieves window level of the widget including
focused element. But this is unsafe to flush the layout. So, we need to stop
flushing layout in this case.
Therefore, this patch moves the `#ifdef` from `TextEvents.h` to
`IMEContentObserver.cpp`, then, makes `nsChildView::GetEditorView()` use
`eQueryContentState` which is the simplest query content event, and finally,
sets `mNeedsToFlushLayout` to `false`.
Differential Revision: https://phabricator.services.mozilla.com/D25912
--HG--
extra : moz-landing-system : lando
Splitting part of OGLShaderProgram.h out into OGLShaderConfig.h makes it
easier to keep GLContext.h included in OGLShaderProgram.h for inlining
purposes.
Differential Revision: https://phabricator.services.mozilla.com/D20017
--HG--
extra : moz-landing-system : lando
widget/cocoa/nsChildView.mm:249:6 [-Wmissing-prototypes] no previous prototype for function 'EnsureLogInitialized'
Depends on D20087
Differential Revision: https://phabricator.services.mozilla.com/D20088
--HG--
extra : moz-landing-system : lando
widget/cocoa/nsChildView.mm:1932:21 [-Wmissing-prototypes] no previous prototype for function 'TextureSizeForSize'
widget/cocoa/nsCocoaUtils.mm:351:6 [-Wmissing-prototypes] no previous prototype for function 'data_ss_release_callback'
Differential Revision: https://phabricator.services.mozilla.com/D20087
--HG--
extra : moz-landing-system : lando
This is a clearer implementation that achieves the same thing.
Moreover, disabling the clearing by overriding drawRect wouldn't work in
CoreAnimation windows because in CoreAnimation windows, the clearing happens
through a property of the NSVisualEffectView's CALayer, and not through the
view's drawRect implementation - drawRect probably isn't even called in that
context.
Differential Revision: https://phabricator.services.mozilla.com/D19601
--HG--
extra : moz-landing-system : lando
This has two advantages:
- The drawing will now correctly be placed "on top" of the vibrancy views.
- We can turn this new view into a layer-hosting view. Layer-hosting views are
supposed to be leaf NSViews; they shouldn't have any children.
Differential Revision: https://phabricator.services.mozilla.com/D19600
--HG--
extra : moz-landing-system : lando
NSView hierarchy before:
- window contentView
- ChildView
- NonDraggableView 1
- NonDraggableView 2
- EffectViewWithoutForegroundVibrancy 1
- EffectViewWithoutForegroundVibrancy 2
NSView hierarchy after:
- window contentView
- ChildView
- ViewRegionContainerView
- NonDraggableView 1
- NonDraggableView 2
- ViewRegionContainerView
- EffectViewWithoutForegroundVibrancy 1
- EffectViewWithoutForegroundVibrancy 2
This allows us to give those container views a new sibling view which stays
fixed in z-order with respect to the NSViews that get created by
mNonDraggableRegion and mVibrancyManager. More specifically, I'm going to add a
view for the drawing of our ChildView ("PixelHostingView") which is going to be
a direct child of the Gecko "ChildView" and a sibling of the
ViewRegionContainerViews; the PixelHostingView needs to always stay on top of
the vibrancy views.
Without the wrapper around the vibrancy views, whenever the vibrant region
changes, a vibrant view would be placed on top of the PixelHostingView and the
order would be wrong.
Differential Revision: https://phabricator.services.mozilla.com/D19598
--HG--
extra : moz-landing-system : lando
This was added in bug 476393 in order to work around a problem with the Java plug-in.
We no longer support that plug-in.
The comment also mentions NSTexturedBackgroundWindowMask which we stopped using in bug 1335191.
Differential Revision: https://phabricator.services.mozilla.com/D19558
--HG--
extra : moz-landing-system : lando
This method could only return something non-null in embedding situations,
in which our ChildView was a subview of somebody else's NSView that conforms
to the mozView protocol. Such a situation hasn't existed for about 10 years.
Differential Revision: https://phabricator.services.mozilla.com/D19555
--HG--
extra : moz-landing-system : lando
This cleans up a bit and allows us to be smarter about which cursors
should we allow from content or what not, which will help with bug 1445844 and
co.
Differential Revision: https://phabricator.services.mozilla.com/D16711
Our implementation of this method was removed in bug 1070710. I forgot to remove the declaration in that bug.
Differential Revision: https://phabricator.services.mozilla.com/D7947
--HG--
extra : moz-landing-system : lando
This was separate because at some point in the past we were calling
-[ChildView drawRect:inContext:] from a separate draw-in-titlebar pass. That separate
pass was removed in bug 676241.
Depends on D7929
Differential Revision: https://phabricator.services.mozilla.com/D7931
--HG--
extra : moz-landing-system : lando
