We have stopped dispatching "keypress" events for non-printable keys
and key combinations for conforming to UI Events and following the
other browsers.
However, this change hits a serious bugs of Google Docs, Google
Spreadsheets and Gmail. Until they will fix their bugs, we should
take back the traditional behavior for keeping Nightly usable for
any Nightly testers.
MozReview-Commit-ID: 9CyEbsFit1S
--HG--
extra : rebase_source : 837288b1fb53121badff4e65094a87cebfe3cfee
Some themes (Ambiance for instance) uses first-child/last-child css selectors
to style titlebar buttons. Ubuntu Ambiance theme places titlebar buttons closer
by negative margin applied to them.
We put titlebar buttons to GtkBox as well as Gtk+ does and also keep
the button order here to match first-child/last-child selectors. It also means
we must have maximize/restore as one button to keep the correct order.
MozReview-Commit-ID: 9mqljOa4Vu7
--HG--
extra : rebase_source : 9c31a2073d1bb247ce9d0240333143661b8ae4b8
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
This a remaining issue of bug 1435180. We need to skip keypress event check of
non-printable key operation in the test.
MozReview-Commit-ID: InobZCbrzWL
--HG--
extra : rebase_source : 9f17cd04500f4ef31c3674087188ec6ee157173b
UI Events declares that keypress event should be fired only when the keydown
sequence produces some characters. For conforming to UI Events and
compatibility with the other browsers, we should stop dispatching keypress
events for non-printable keys.
For getting regression reports, we should enable this new behavior only
on Nightly and early Beta.
MozReview-Commit-ID: 5IIL9huejXH
--HG--
extra : rebase_source : 0abdbe84a50d6fd1b4d52521b92e7513483b197c
https://bugzilla.mozilla.org/show_bug.cgi?id=1418749
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 : 92cbe495ce097b080a9f94ec5312169da9a8648d
We still get occasional messages for the internal OLE Main Thread window.
Also, the PeekMessage call allows internal windows messages to be processed for
things like GDI.
GtkHeaderBar has property "spacing" which defines space between buttons at titlebar.
Get this property and apply as margin to titlebar buttons when there's more than one.
Also cache this value for furter use at titlebar metrics cache.
MozReview-Commit-ID: J7qAIWEnK4Y
--HG--
extra : rebase_source : 73f0f605444cf4e4ada3da335ff003e9df05c9c4
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
A lot of "WARNING: Invalid monitor scale: -1" appering for the puppet widget since
fix for bug 1439881 landed. We don't need to print the warning, fallback to 1 is
sufficient enough.
MozReview-Commit-ID: 73BGc8neUmu
--HG--
extra : rebase_source : 74b2a818a29514095b5c56b05966cff5e4e9ba60
This is particularly useful for knowing when it's safe to query for style and
layout information for a window without causing a synchronous style or layout
flush.
Note that promiseDocumentFlushed was chosen over promiseDidRefresh or promiseRefreshed
to avoid potential confusion with the actual network-level refresh of browsers or
documents.
MozReview-Commit-ID: Am3G9yvSgdN
--HG--
extra : rebase_source : 20bdd2d6f624767d919d95a6601fc1c890aadf10
This is particularly useful for knowing when it's safe to query for style and
layout information for a window without causing a synchronous style or layout
flush.
Note that promiseDocumentFlushed was chosen over promiseDidRefresh or promiseRefreshed
to avoid potential confusion with the actual network-level refresh of browsers or
documents.
MozReview-Commit-ID: Am3G9yvSgdN
--HG--
extra : rebase_source : 20bdd2d6f624767d919d95a6601fc1c890aadf10
This gtest assumed the current working directory ($OBJDIR/_tests/gtest/) was in the DLL LoadLibrary path. That is no longer true with this bug's patches, so the gtest must specify the absolute path to the PDFium DLL to load it.
MozReview-Commit-ID: 5TXj6A9Tb9w
--HG--
extra : rebase_source : b097ae0c3430767e9ff16632ee96fd8739a902bf
extra : histedit_source : 1f13fa04c29039f8aeae05028d0a20ede5ee794b
Because of rounding errors there's a change that returned monitor scale
is 0. That would lead to SIGFPE because it's later used in division.
MozReview-Commit-ID: 4d7nHaBm4XG
--HG--
extra : rebase_source : d7fb5c64698d1e99afc223d401b30e0eb168fdb4
Windows default behavior will trigger the System menu bar when F10 is released.
Among other things, this causes the System menu bar to appear when a web page overrides the contextmenu event.
We *never* want this default behavior, so eat this key (never pass it to Windows).
MozReview-Commit-ID: 4fWOuj4mWvW
--HG--
extra : rebase_source : 45d38ba19b2f23aca74a60819c7d93af2ffa167d
Although we haven't any bug reports caused by this, this is a really old bug.
When we implement TSFTextStore, we decided to use queue of dispatching
events and flush it when document lock is unlocked. When we implement the
queue, we got this regression.
When TSFTextStore::SetText() is called with different range from current
selection range, TSFTextStore::SetSelectionInternal() add
PendingAction::SET_SELECTION into the queue first for replacing existing
text or inserting text into different position if there is no composition.
Then, TSFTextStore::InsertTextAtSelectionInternal() inserts text at the new
selection range.
When TSFTextStore::FlushPendingActions() is called after that, eSetSelection
should be dispatched and then, new text is inserted wit a set of composition
events. However, we forgot to dispatch creating eSetSelection event.
So, this patch just dispatches the event.
MozReview-Commit-ID: Hw8FTB1R5kR
--HG--
extra : rebase_source : 8a119f1f48b167d9423fc89ce0efc722313c3732
This allows apps to decide which GeckoSession should handle a load that
will be in a new window (e.g., window.open()).
MozReview-Commit-ID: BkJM93489Ga
Gecko decides keyCode from an ASCII character which is produced by the key
by itself or with Shift on active keyboard layout or alternative ASCII capable
keyboard layout if active keyboard layout isn't ASCII capable. However, we've
ignored alternative ASCII capable keyboard layout's character if both the
key itself and with Shift don't produce ASCII alphabet nor ASCII numeral,
i.e., ASCII punctuation characters are not used in alternative ASCII capable
keyboard layout because of avoiding mapping a keyCode value to 2 or more keys.
However, setting 0 to keyCode value makes Firefox unusable with some web
applications which are aware of neither KeyboardEvent.key nor
KeyboardEvent.code. So, even if we map same keyCode value to a key, we should
avoid setting keyCode value to 0 as far as possible.
This patch's approach is, we behave same keyCode value as the alternative ASCII
capable keyCode is selected when computed keyCode value of active keyboard
layout is 0. This means that we will make some language users whose keyboard
layout for their language is not ASCII capable can use global web services
which support US keyboard layout of Firefox since the new keyCode values
are mostly computed with US layout on Windows or actual alternative ASCII
capable keyboard layout on macOS and Linux. In other words, we cannot improve
compatibility with web applications which don't support Firefox by this patch
since our keyCode values are really different from Chrome's. So, unfortunately,
if we'd use exactly same keyCode computation as Chromium, we'd break
compatibility with existing web applications which are aware of Firefox since
it's necessary to check UA name or something before using keyCode values.
Note that the most important difference between Windows and the others is,
such keyCode value is computed with alternative ASCII capable keyboard
layout on macOS and Linux but only on Windows, it's computed with OEM virtual
keycode. This means that only on Windows, the keyCode value may be different
from actual alternative ASCII capable keyboard layout's keyCode.
MozReview-Commit-ID: As289r9wp6i
--HG--
extra : rebase_source : 66181403dbe8ca8dab893edc8f4eec1991d544d0
We instead add a templated method NS_MutatorMethod that returns a std::function<nsresult(nsIURIMutator*)> which Apply then calls with mMutator as an argument.
The function returned by NS_MutatorMethod performs a QueryInterface, then calls the passed method with arguments on the result.
MozReview-Commit-ID: Jjqp7gGLG1D
--HG--
extra : rebase_source : f2a17aee7bb66a7ba8652817d43b9aa7ec7ef710
