I'm replacing non-failing calls to NS_NOTREACHED with MOZ_ASSERT_UNREACHABLE, but this NS_NOTREACHED fails when running the browser/base/content/test/general/browser_tab_dragdrop2.js test because mContainer is unexpectedly *not* null. This is bug 1469183.
This patch DOES NOT fix the cause of the assertion failure. It just replaces this failing NS_NOTREACHED with NS_ERROR because I can't replace with a fatal MOZ_ASSERT_UNREACHABLE.
MozReview-Commit-ID: KeVjvKGihxZ
--HG--
extra : rebase_source : dc08a8e15d1e98cda0fa755be43c6d06910bfbe8
extra : intermediate-source : 562cc0bfc636f29b1708acd3284567bb8492e030
extra : source : 4f14f18eccd6bb18ed92f1d39a265a30ccdd21a1
It's based on a solution by Takuro Ashie <ashie@clear-code.com>
MozReview-Commit-ID: FqcdUJQJLdl
--HG--
extra : rebase_source : d4ed4d66439a3693a2f4d5e6a4037ed62969d64f
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : 344c380ddaaf42a1fd820a26b762c61ee9e2d524
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : f807c14bf6a592e0c651e15b63d1e7d63e4b0159
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : 35362bc94068103367f46b23a14cb3831cd86990
In the case of a long-tap touch sequence, a new popup window (the
contextmenu) is spawned while the sequence is ongoing. The touch-end of
the sequence ends up getting delivered to the popup window, instead of
the original content window, and that causes the touch-handling
machinery state in the content window to get out of sync with reality.
This patch detects this scenario and redirects the touch events on the
popup window back to the original content window.
MozReview-Commit-ID: L2vvKLlogRA
--HG--
extra : rebase_source : fd4c36c93e45d05155d415f6470e12979b9a675b
This patch implements Drop operation on Wayland/Gtk+. That's because drop operations are part
of clipboard on Wayland and we use our own paste clipboard handler on Wayland (Bug 1282015).
Wayland drop data are provided by wl_data_device_listener, it provides us drag and drop callbacks
which we route to nsDragService module.
MozReview-Commit-ID: 9uGYPg9YF6P
--HG--
extra : rebase_source : 613c079960d5d8522609374ce7e9ad23d5908f3f
Original patch author is Takuro Ashie <ashie@clear-code.com>
Provide ability to create native EGL window and provide it under NS_NATIVE_EGL_WINDOW
to GL code. The native EGL window is owned/managed by mozcontainer.
MozReview-Commit-ID: 4d0Kk6DRSaD
--HG--
extra : rebase_source : e4677ce51fbf918eb1b0257c66ca4b7220174bbb
Implement SetCompositorHint() which sets _NET_WM_BYPASS_COMPOSITOR GtkWindow property when it's recreated
at nsWindow::SetDrawsInTitlebar().
Window role/class is handled by nsWindow::RefreshWindowClass(), it uses stored window class
passed to nsWindow::SetWindowClass().
MozReview-Commit-ID: 1JJsK1ZQyvu
--HG--
extra : rebase_source : 004fe2e379bf1ca2f157ef8df66c5875ab2c135c
So as to provide a sensible size for the window when the user exits maximized
state.
MozReview-Commit-ID: DSXawb85xmL
--HG--
extra : rebase_source : b65f9d8238061dab4b53ef2282d1d1102ec11ace
Implement and use solid-csd decoration style to get window offset when solid-csd is used by mShell toplevel window.
Also does not apply margin (resize handler sizes) on popup window as well as Gtk+ do in get_shadow_width().
MozReview-Commit-ID: 9xozp9CCVJj
--HG--
extra : rebase_source : 687993d60b8f2063ed31f07ba2d7ab9f1faa09c8
When system titlebar rendering is disabled and we're in CSD window mode, the window decorations are
rendered by client (application/Gtk) and we don't get _NET_FRAME_EXTENTS property (decoration size) update
for our toplevel window.
So we need to calculate the decoration/shadow size as Gtk+ does, we emulate get_shadow_width()
which is not exported by Gtk+.
MozReview-Commit-ID: K7o2rUPt6Yc
--HG--
extra : rebase_source : 86a3f12e760194b5828afed784f6aa02c352e017
uim is an old IM which uses key snooper to listen to key events rather than
via filter key event API which should be called by applications. It's still
used by Debian 9.x, so, we still need to support this.
Unfortunately, we cannot detect if uim actually uses key snooper because it's
switch by build option of uim. Currently, Debian builds uim as using key
snooper. So, we should assume uim uses key snooper always. On the other
hand, somebody *might* use uim built as not using key snooper, so, let's
decide if uim uses key snooper with new pref,
"intl.ime.hack.uim.using_key_snooper", but its default should be true.
Note that ibus and Fcitx also have the mode to use key snooper (perhaps for
backward compatibility with uim). However, it's not enabled in default
settings and even if it's enabled, Firefox is in whitelist in the default
settings of them for stop using key snooper. Therefore, we don't need to
support key snooper mode for them unless we'll get some requests to
support their key snooping mode.
MozReview-Commit-ID: 6fTsfKrHzvo
--HG--
extra : rebase_source : 8ddf4541db635246e6bb0ddc73b012c9be001c6d
CLAMP is unnecessary as the minimum acceptable value is 0, and
progressPercent is unsigned. CLAMP can trigger the following warning/error in some builds:
error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
--HG--
extra : rebase_source : 0dfcf4286a74adac03f7498f1d35fee069528826
For conforming UI Events spec, KeymapWrapper::InitKeyEvent() should initialize
mKeyCode and mKeyNameIndex with NS_VK_PROCESSKEY and KEY_NAME_INDEX_Process if
given keyboard event has already been handled by IME.
For making it know if given keyboard event has been handled by IME, this patch
adds additional bool argument to it and its callers.
Note that this patch changes keyCode value and key value of "keydown" event if
it's fired before "compositionstart" since Chromium does so on Linux.
MozReview-Commit-ID: FC3tfyeeopU
--HG--
extra : rebase_source : b7e2a70db1fbb4ca7d20379fd1c14f7dc38e656d
This adds support for download progress reporting via the XApp
method currently used in the Cinnamon desktop, by establishing a new
X11 window property to be supported/read by the window manager.
See https://github.com/linuxmint/xapps/blob/master/libxapp/xapp-gtk-window.c,
as well as https://github.com/linuxmint/muffin/commit/39045da0ea06f
for more details.
The property-setting code lives in nsWindow - it's a small and stable
enough chunk that it made more sense to do this than actually depend on
another external library. As nsWindow is already using x11 calls, this
seemed the safest place for it, without affecting the build.
The TaskbarProgress instance is initialized via the DownloadsTaskbar
js module, and is handed a pointer to the current main window to call
SetProgress on. Most of the javascript side of this is in line with
how the other platforms are handled.
Without a supporting window manager/desktop environment (currently just
Cinnamon/Muffin 3.6,) the simplest way to observe working behavior is
by calling 'xprop -spy' on the browser window being testing and watching
for updates during a download.
--HG--
extra : rebase_source : 0606f6c87116204ec290c19276072d0c1c35691e
The titlebar rendering on Linux/Gtk+ is recently enabled at Beta59 but with many bugs fixed at Nightly.
Let's disable this feature for Beta / Release 59 and ship it at Firefox 60 where majority of the issues are fixed.
MozReview-Commit-ID: FQL7tNhcvUG
--HG--
extra : rebase_source : 03a495ebc81b5ae5b4093406bd40daf83251343a
The DispatchEvent can manipulate with the mRefPoint we're later using to check if the
double click happened on the titlebar. We need to save it for later check to avoid
unwanted restore/maximize event when mouse event occurs near top border of any widget.
Also don't handle doubleclick on titlebar when CSD is not enabled.
MozReview-Commit-ID: KjxM1EsT4Lg
--HG--
extra : rebase_source : b880e4d89ebe3546b7ef70e3d94926a628f98598
We need to use scaling factor of the monitor on which application is actually positioned.
Previously we used ScreenHelperGTK::GetGTKMonitorScaleFactor() which use the first monitor.
This does not work on hidpi+normal dpi monitors setup.
The GetSystemFontInfo() cannot return scaled value of the font by default monitor
scale factor. We need to scale it in nsLookAndFeel::GetFontImpl
by aDevPixPerCSSPixel like implementation for Windows does.
We also need to check layout.css.devPixelsPerPx because we cannot
scale per monitor when this preference is set to positive number.
MozReview-Commit-ID: AwT2NvkEqvz
--HG--
extra : rebase_source : 5b956a6abd7d215b06ebcd8c56e34c038d012940
The drag area should process doubleclick event as request for restore/maximize
because otherwise there's no other option to do the action when Firefox
is drawing window decoration. We follow similar path as mac which handles this
in mouseUp event.
MozReview-Commit-ID: KpCnHTdteLr
--HG--
extra : rebase_source : bf0680e33fd5a5b6c931b5260430fdd3fd995769
We need to use scaling factor of the monitor on which application is actually positioned.
Previously we used ScreenHelperGTK::GetGTKMonitorScaleFactor() which use the first monitor.
This does not work on hidpi+normal dpi monitors setup.
The GetSystemFontInfo() cannot return scaled value of the font by default monitor
scale factor. We need to scale it in nsLookAndFeel::GetFontImpl
by aDevPixPerCSSPixel like implementation for Windows does.
We also need to check layout.css.devPixelsPerPx because we cannot
scale per monitor when this preference is set to positive number.
MozReview-Commit-ID: AwT2NvkEqvz
--HG--
extra : rebase_source : 36d64957e017486d99c4302346ab64e47b5e2cc6
The change to RootAccessible.cpp fixes an obvious bug introduced in bug 741707.
The visibility changes in gfx/thebes are because NS_DECL_ISUPPORTS has a
trailing "public:" that those classes were relying on to have public
constructors.
MozReview-Commit-ID: IeB8KIJCGhU
Some compositors such as GNOME mutter use heuristics to unredirect fullscreen
windows in an effort to reduce output latency. This works fine for applications
that take the proper steps to ensure all framebuffer updates happen in the
vblank interval. Since this is not currently the case for Firefox, bypassing
the compositor will lead to frame tearing.
Set _NET_WM_BYPASS_COMPOSITOR to 2 to opt out of fullscreen unredirection.
MozReview-Commit-ID: 1xW2VAnbiJw
--HG--
extra : rebase_source : 77c4ae490413057d8d9dadf9b155c86ddbbcb4b5
Also comment existing entries at nsWindow::GetCSDSupportLevel().
MozReview-Commit-ID: 1YzZhv7WrQj
--HG--
extra : rebase_source : c1dd1a3452e13e2479afee3c34d396757dae4cfd
