This removes the need for the content process to have permissions to create new
files on macOS, allowing more aggressive sandboxing.
MozReview-Commit-ID: 8agL5jwxDSL
--HG--
extra : rebase_source : 17ebcef3e9d24f3d4e7515e3fae95e65cef76a79
Values taken from running Firefox on Ubuntu with GTK.
MozReview-Commit-ID: K3aDicUBr8q
--HG--
extra : rebase_source : 3d9634a5398b768d091414ba76e2b8a027689832
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
TIP name of ATOK Passport's ATOK 31.1.2 is just "ATOK", not "ATOK " + release
year. Therefore, TSFStaticSink::IsATOKActiveInternal() returns false when
new ATOK is active. This patch updates it.
Additionally, this patch adds GUID list of new Japanese TIPs with comment.
They should be useful when somebody needs to add hack for them.
MozReview-Commit-ID: 6L5SjWEK6i0
--HG--
extra : rebase_source : e3ac9eb1377ee9143a4e2e9fa2ce4be98983bb4b
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
The renaming problem is, when I try to convert 2nd or later clause of
composition string with Japanist 10, it shows candidate window below the
start of composition string first, then, it moves candidate window to
below the selected clause. This is caused by our bug of the hack in
TSFTextStore::GetTextExt().
First, we compute wrong minimum modified
offset of mContentForTSF. It stores last composition string when it's
initialized. Then, when a part of composition string is modified, it
sets minimum modified offset with the last composition string. However,
we don't update it when we receive notifications from content which means
all dispatched composition events are handled in content and
ContentCacheInParent stores character rects at least in this time. So,
this patch adds TSFTextStore::Content::OnCompositionEventsHandled() to
update the last composition string.
Next, TSFTextStore::GetTextExt() always adjusts acpStart to start of
composition string when acpStart is larger than composition start.
However, this causes this remaining problem. If ContentCacheInParent
stores character rects of even older composition string, we should use
it as far as possible. This must not be problem in most cases since
most Chinese characters and Japanese Kana characters have same width.
This touches share code of the hack between any TIPs. However, this must
not be risky because this patch just reduces amount of adjusting acpStart
offset in safe range.
MozReview-Commit-ID: KlDeaGa26UG
--HG--
extra : rebase_source : 6d906f9810b8e067018f7ff3ab2fd31f5bef49f6
Similar to ATOK, Japanist 10 requests all or part of composition string.
If we return TS_E_NOLAYOUT in this case, you'll see candidate window at
top-left of the screen.
For avoiding this issue, we should not return TS_E_NOLAYOUT to Japanist 10
when the query range is in composition string.
MozReview-Commit-ID: 2OPafUO5PQC
--HG--
extra : rebase_source : bd7a594d8d3540374d61860651b69528aa6e3793
nsIDOMWindowUtils.sendKeyEvent() can dispatch any keyboard events, i.e.,
may dispatch different key events from actual Gecko's behavior. Instead,
they should use nsITextInputProcessor directly or synthesizeKey() of
EventUtils which wraps nsITextInputProcessor.
MozReview-Commit-ID: EDWqXy1OxJp
--HG--
extra : rebase_source : 158c6f3d1611646540133297e4c8352e0b85ab79
Also comment existing entries at nsWindow::GetCSDSupportLevel().
MozReview-Commit-ID: 1YzZhv7WrQj
--HG--
extra : rebase_source : c1dd1a3452e13e2479afee3c34d396757dae4cfd
The unified headers already define the keycodes in
GeckoEditableSupport.cpp, so only define them ourselves when not using
unified headers (by checking the __ANDROID_API_X__ macros).
MozReview-Commit-ID: 3Ptakcm0rW
--HG--
extra : rebase_source : c7baf2fc9c02cc891946a197fb17309d3593a610
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
Render titlebar button icons as a part of -moz-window-button-* appearence. It allows us to
theme the icons accordingly. We add a GtkImage widget to header bar buttons as Gtk+ does and
store icon pixel data there and render it at moz_gtk_header_bar_button_paint() as a part
of the buttons. It means that the toolbar buttons are not containers and
moz_gtk_get_widget_border() returns zero border for them.
Also implement GetToolbarButtonMetrics() per button.
MozReview-Commit-ID: gkAu3VmE3q
--HG--
extra : rebase_source : d1df34537901342969d1e33524b414a2786df541
And disallow using copy constructor and copy assignment for the structs.
MozReview-Commit-ID: 7jSktlu1SqN
--HG--
extra : rebase_source : cc8bcb1f95843a2a46a044e226c299a6196ef2a2
The copy-assignment in this patch is used in the copy-constructor.
Note that we can't simply use '= default' implementation since we need to use
MOZ_COUNT_CTOR() in the move constructor.
MozReview-Commit-ID: 8HTMaTONBuN
--HG--
extra : rebase_source : 7da0586e0772a2d71455492412d40780c59558e5
The unified headers already define the keycodes in
GeckoEditableSupport.cpp, so only define them ourselves when not using
unified headers (by checking the __ANDROID_API_X__ macros).
MozReview-Commit-ID: 3Ptakcm0rW
--HG--
extra : rebase_source : 01c302fa92ea00374d8f1dae326670dd98ad3ec8
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
Chromium dispatches a keypress event when pressing Enter or Shift+Enter.
Actually, when user press them in <pre> element of HTML editor, ツ・n is inserted.
It makes sense to treat the key combinations as inputting text.
MozReview-Commit-ID: Hvx87MZtZkn
--HG--
extra : rebase_source : 196b63843ebcb6e4b398f6b21a4f5f1d020b8db3
UI Events declares that keypress event should be fired when the keypress event
causes some text input. However, we're keeping our traditional behavior for
historical reasons because our internal event handlers (including event
handlers of Thunderbird) handles keypress events for any keys. Therefore,
for minimizing the side effect, we should stop kicking keypress event handlers
in the default event group in web content.
This patch adds new pref for enabling the standard behavior in web content.
Additionally, creates WidgetKeyboardEvent::IsInputtingText() for sharing the
check logic between TextEventDispatcher and TextEditor/HTMLEditor.
MozReview-Commit-ID: 3rtXdLBPeVC
--HG--
extra : rebase_source : 2fc3c9a09840d0d03800c9a42bb83ca76a8db2d5
TextInputHandler::HandleCommand() has two bugs. One is, checking whether
the key event has caused composition events. Even if it caused composition
events, we decided to dispatch keypress event for emulating native behavior.
Therefore, this patch removes the check of
|currentKeyEvent->CanDispatchKeyPress()|.
The other is, for making content handle dispatching keypress event as given
command, it needs to dispatch a keypress event whose key combination will
cause the command. However, HandleCommand() needs to set native key event
since content may not refer key combination for some edit actions, they just
refer command which is computed with native key event with NativeKeyBindings.
Therefore, even if current native key event has already caused dispatching
some events, HandleCommand() needs to set
WidgetKeyboardEvent::mNativeKeyEvent to current native key event for
NativeKeyBindings. Although it must be rare case, given key could be
not related to the command or not key could cause the command. In this
case, and perhaps in all cases, we should set all commands of dispatching
keypress event before dispatching it. Howevever, this needs more work,
so, we shouldn't do it in this bug to making it possible to uplift.
Therefore, this patch makes always set mNativeKeyEvent to current native
key event. So, just warning it when command is caused without native
key event.
MozReview-Commit-ID: 2MvDTw4ruAu
--HG--
extra : rebase_source : 02a4ca980530aa16fa0e1aecd6d18fa42873c1dc
extra : source : 1e3137db3fe9822f34b98d59fb928497caca466a