This patch does the following.
- Uses "entries" consistently for the name of the value that is obtained from
MOZ_PROFILER_ENTRIES and is the first argument to profiler_start(). (I.e. not
"entry" or "entrySize".)
- Removes variables (e.g. PROFILER_HELP) holding env var names and uses the
names (e.g. "MOZ_PROFILER_HELP") directly. Some of the names are already used
directly and I think the slight repetition isn't harmful. It's unlikely that
we'd want to change these names the way we might need to change a numeric
value, and they're perfectly descriptive.
- Changes the "MOZ_PROFILING_FEATURES" string in the weird Android-only startup
code to be "MOZ_PROFILER_FEATURES", for consistency.
- Renames gUnwindInterval and gProfileEntries as gEnvVarInterval and
gEnvVarEntries to make it clearer that they come from environment variables,
but otherwise are parallel to gInterval and gEntries.
- Puts entries before intervals in most places, to match the profiler_start()
argument order.
- Changes profiler_usage() so that (a) it always prints, no matter the
verbosity, (b) it exits at its end, and (c) doesn't double-print "Profiler: "
at the start of each line.
--HG--
extra : rebase_source : e5a0b1c48e390ada894c746f050f08ff5c241066
Changed |print("enum ID : uint32_t {", file=output)| to |print("enum HistogramID : uint32_t {", file=output)| at line 53 of the file |toolkit/components/telemetry/gen-histogram-enum.py|, and then replaced all the textual occurrences of |Telemetry::ID| to |Telemetry::HistogramID| and |ID| to |HistogramID| in 43 other files.
More JPZ leftovers, I presume. In any case what's left doesn't do anything really useful and a DXR search didn't reveal any remaining users, so this can be thrown out.
MozReview-Commit-ID: 9dN6Jifpbvw
--HG--
extra : rebase_source : 04614d729a55e00c5331ecc321ca2ef5b5e73747
Korean IME and some other simple IME may not use marked text at composing text. Such IME modifies composing character with InsertText() with aReplacementRange. Then, when
user types new character, such IME may replace the previous character with a call of InsertText() with aReplacementRange and insert the next character with additional call of InsertText() without aReplacementRange.
In this case, InsertText() ignores the call when the native keydown event is already caused composition events. However, we need to allow to dispatch keypress event for supporting to insert text even in such case.
This patch checks if inserting text is printable. If it's not a printable character such as U+000A at pressing Enter, keeping current behavior. Otherwise, dispatching keypress event instead.
MozReview-Commit-ID: 5NcCgXfvniO
--HG--
extra : rebase_source : f05db8655d623880cb658cef144d1e9fcdce8a2a
For a table, the primary frame is the table wrapper anonymous box. That
anonymous box inherits style from its _child_ table frame, which is the frame that
has the actual style for the element. So we want to use the stylo-computed
style for the table frame, and then compute an updated style for the table
wrapper too, because some things (like absolute positioning) are done for the
table wrapper anonymous box, not the table frame.
From https://developer.apple.com/reference/objectivec/1418956-nsobject/1418583-respondstoselector :
> You cannot test whether an object inherits a method from its superclass by
> sending respondsToSelector: to the object using the super keyword. This method
> will still be testing the object as a whole, not just the superclass’s
> implementation. Therefore, sending respondsToSelector: to super is equivalent
> to sending it to self. Instead, you must invoke the NSObject class method
> instancesRespondToSelector: directly on the object’s superclass.
MozReview-Commit-ID: 8wTexCQWUPw
--HG--
extra : rebase_source : f392bfe75c0a5c270b12b0f4ea2abdc6f737d5c2
Android uses android.os.SystemClock.uptimeMilles for event time and SystemClock.uptimeMilles uses SYSTEM_TIME_MONOTONIC.
So since TimeStamp posix impelemetation uses SYSTEM_TIME_MONOTONIC too, so we can use event time on FromSystemTime.
MozReview-Commit-ID: 5Qb5kmnHHCI
--HG--
extra : rebase_source : 26d1554fa60e3216edfd4b149380910fe2a9d845
Shift + Tab key combination causes ISO_Left_Tab keysym instead of Tab. It should be mapped to DOM Tab key.
MozReview-Commit-ID: IgQj7tkQdoJ
--HG--
extra : rebase_source : 2f88c1181795d568ac4ec785f416d986d8d6625e
Bug 1180564 dropped NSTextInput protocl implementation from ChildView but IMEInputHandler::SendCommittedText() still calls it via mView. Therefore, it fails to commit composition in widget level. Instead, we it should call insertText:replacementRange: of NSTextInputClient protocol.
Additionally, this patch adds a last resort path. If calling insertText:replacementRange: didn't commit composition in widget level, it calls TextInputHandler::InsertText() directly.
MozReview-Commit-ID: BZZypBqC0Mx
--HG--
extra : rebase_source : bef5612a933db3211400e9d8bd2848690de2d2e5
Currently, we use alias NS_VK_* for WidgetKeyboardEvent::mKeyCode. Similarly, we should create alias enum for nsIDOMKeyEvent::DOM_KEY_LOCATION_*. Then, we can reduce the length and avoid to include nsIDOMKeyEvent in some cpp files.
MozReview-Commit-ID: 5cs4zQ061Lc
--HG--
extra : rebase_source : e6a6edd27718b9e3d4a40b07902d029791876999
There are still a lot of crash due to failing to get following WM_CHAR message. Almost half of them are, we found a WM_CHAR message but it's gone at removing the message from the queue.
Although, we're still not sure what happen actually. It could be possible if somebody hooks PeekMessage() or something. Then, we can assume that the found message isn't necessary for the user because it must be removed by somebody when it became unnecessary or is handled.
This patch mark a new bool flag, mCharMessageHasGone, as true in such case. Then, NativeKey will dispatch keypress events without following char messages and mark the event as consumed.
MozReview-Commit-ID: mporX1sihC
--HG--
extra : rebase_source : a1badc205a99efd803de624d24b69e911f81d308
NativeKey::GetFollowingCharMessage() may remove a char message which is different from previously found message in the queue because hacky keyboard layout or utility can overwrite the wParam when it's removed from the queue.
Now, we should assume that newer message, i.e., actually removed from the queue, is the expected message by the user. See bug 1336028 comment 0 for the actual scenarios which are collected by crash reports.
https://bugzilla.mozilla.org/show_bug.cgi?id=1336028#c0
MozReview-Commit-ID: 9ZgukHH1vfi
--HG--
extra : rebase_source : 15559e62882f97d5062703e2308fa1c22016f340
Currently, NativeKey::GetFollowingCharMessage() tries 5 times to remove found char message from the queue. It was enough when we found this issue at developing Metrofox.
However, this hack is not enough for some odd keyboard layouts because we see some crash reports which gives up to remove a char message from the queue because 5 WM_NULL messages are returned.
For preventing this crash, we should check if there is the message which is trying to remove from the queue when NativeKey receives WM_NULL. Then, when there is no key message in the queue or next key message becomes non-char message,, NativeKey should dispatch consumed keydown event because we can assume that the key operation may have already been handled or canceled. Otherwise, NativeKey should retry to remove the message again (until 50 times!, it's just enough big magic number, there is no concrete reason).
MozReview-Commit-ID: 1c6Y4OoQdrP
--HG--
extra : rebase_source : 2ad588d0513741ff6a58be6f523cf59d8deea151
I think that when PeekMessage(PM_REMOVE) failed to remove a char message but next key message is still a char message, it may be possible that the odd keyboard layout or utility hook only PeekMessage(PM_NOREMOVE) and GetMessage(). If so, we can explain what occurs in this case.
I'm still not sure this fixes the case of bug 1336322 comment 0, but we should try to do this because I don't have better idea.
MozReview-Commit-ID: CxoO24n167t
--HG--
extra : rebase_source : c00b86166a345eec18fa2de74698f6e8859364b8
This patch depends on bug 1336080.
When PeekMessage() fails to remove found char message, NativeKey::GetFollowingCharMessage() tries to check next key message in the queue again. Then, when next key message becomes non-char message, such as WM_KEYDOWN or WM_KEYUP, the char message must be removed by odd keyboard layout or something. Similarly, when next key message is a char message but it's caused by different key, the found char message must be removed by one of them too.
So, in these cases, NativeKey::GetFollowingCharMessage() should treat the key operation is already handled or canceled by the odd keyboard layout or somebody else. Additionally, in the latter case, following char message should be handled as orphan char message(s) as usual.
MozReview-Commit-ID: 8ahs8I0HUQ2
--HG--
extra : rebase_source : 563efc0e65c1d400a32cb0ceec94eb56ad0aa1c5
When NativeKey::GetFollowingCharMessage() tries to remove a char message from the queue, the message might be changed by odd keyboard layout or something. In such case, if the new char message is also caused by same physical key, the char message must be overwritten. Then, we should take the new char message instead.
Note that this patch saves original found char message into kFoundCharMsg and it's logged by each points for indicating if this case has occurred.
MozReview-Commit-ID: HAduq8sfwFt
--HG--
extra : rebase_source : c8980c7fa019fc3e0f249b4506fa572e81f4a1e8
Convert the events used in MediaCastingBar and ChromeCastPlayer to
GeckoBundle/BundleEventListener events. UI thread events are used
because the listener performs operations on the UI thread.
The machinery for suppressing the displayport during live resizes
was using the Observer service. However, in the case of multiple
browser windows, this meant that all the open browser windows would
have their displayport suppressed if *any* of the browser windows
was being resized. This was mostly ok, as the displayport suppression
would be turned off once the resize ended. However, the code to
kick off a repaint with the unsuppressed displayport would only get
triggered on one of the windows (whichever happened to process the
unsuppress message last).
This patch stops using the Observer service for the implementation
machinery, and instead locates the active TabParent of the relevant
nsWindow, and invokes the displayport suppression directly on that.
This fixes the repainting bug and also avoids unnecessarily
broadcasting the suppression/unsuppression notification to windows
that don't neccessarily need it.
MozReview-Commit-ID: LBHOgOW9KUp
Also guard against a scenario where RecvDocShellIsActive gets called before
we have the layers id for the tab. Because we need to have the compositor
options (which requires knowing the layers id) before we can create the layer
manager, we need to avoid calling GetLayerManager() before we have the options.
MozReview-Commit-ID: 1MKdhvUJobD
This is consistent with GTK not setting these flags with GtkTextView
and GtkScrolledWindow.
The active flag was triggering @selected_bg_color with Ambiance.
This patch almost reverts the state flags to the logic prior to
cd7544affe40 but keeps the focused flag in the scrolled window.
MozReview-Commit-ID: IVY1sI2Hllw
--HG--
extra : rebase_source : 5774af02f7b6abfeab15bee5f35d941490c81514
Currently, EventListenerManager calls WidgetEvent::PreventDefault() when the status is nsEventStatus_eConsumeNoDefault. That causes unexpected state of events. So, WidgetEvent should do nothing when it's not cancelable but PreventDefault() is called.
MozReview-Commit-ID: AjuXCyQpBbi
--HG--
extra : rebase_source : 031c0e129f875b51c58a991b9da9db236ad53ff7
When NativeKey crashes by itself, it means that we detect an impossible situation in usual environment. In such case, active 3rd party's keyboard layout or something other utility may hook API and returns odd result to us.
For investigating the cause and deciding what we should do in such cases, we should collect active keyboard layout name via crash reports.
MozReview-Commit-ID: HYRj24GwDHZ
--HG--
extra : rebase_source : 5f01c2a3b36179a61dc00eebd4de6f05596d217b
As of bug 1325299, WINVER is always >= 0x0601 (Windows 7).
MozReview-Commit-ID: Hw5FcEdP0os
--HG--
extra : source : 239400b39f806592a621473ac3a6dd79b238e725
We were miscounting the number of manual configure events which we
needed to send gtk as the workaround for bug 1225044, causing it not
to work in some cases. This is because configure events can come from
more sources than were counting.
Decrement mPendingConfigures only as far as zero, like
configure_request_count in gtk_window_configure_event().
MozReview-Commit-ID: GxpR2Zozxor
--HG--
extra : rebase_source : 9d02c4d019d8bea7a07c20fb1435d2f677ae6e28
This is needed for GTK themes with non-zero trough-border such as Greybird.
MozReview-Commit-ID: 8ERxq5Nia6F
--HG--
extra : rebase_source : 5e235b6ae9aab334b57a1f669c835eecbb6563fa
