Currently, ContentEventHandler::OnQueryTextRectArray() is used only in e10s mode (at caching necessary character rects in ContentCacheInChild). Therefore, this bug occurs only in e10s mode.
ContentEventHandler::OnQueryTextRectArray() applies CSS transform only to each frame rect. Therefore, character rect's width and height are not applied.
This patch makes the loop apply CSS transform to each character or line breaker rect (i.e., each item of charRects). Then, we need to rewrite the lastCharRect hack. It stores the last charRect value for computing next line breaker rect if next line breaker is caused by a block level element or something, i.e., not caused by a <br> frame. So, when brRect is computed with lastCharRect, the loop needs to apply CSS transform of the last text frame to the following brRect because it tries to compute a caret rect immediately after the last character. For doing this, this patch adds lastFrame which stores the last frame for lastCharRect and set it to baseFrame. Then, at applying CSS transform to each charRect, it can apply CSS transform of expected frame.
Similarly, when brRect is computed with last text frame, this patch looks for the last text frame from lastTextContent and use it as base frame to apply to CSS transform.
MozReview-Commit-ID: 5Yr2HMrooHd
--HG--
extra : rebase_source : fa643f442036d9167a1df3a4383b0802a1729a3e
This change avoids lots of false positives for Coverity's CHECKED_RETURN
warning, caused by NS_WARN_IF's current use in both statement-style and
expression-style.
In the case where the code within the NS_WARN_IF has side-effects, I made the
following change.
> NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
> -->
> Unused << NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
In the case where the code within the NS_WARN_IF lacks side-effects, I made the
following change.
> NS_WARN_IF(!condWithoutSideEffects);
> -->
> NS_WARNING_ASSERTION(condWithoutSideEffects, "msg");
This has two improvements.
- The condition is not evaluated in non-debug builds.
- The sense of the condition is inverted to the familiar "this condition should
be true" sense used in assertions.
A common variation on the side-effect-free case is the following.
> nsresult rv = Fn();
> NS_WARN_IF_(NS_FAILED(rv));
> -->
> DebugOnly<nsresult rv> = Fn();
> NS_WARNING_ASSERTION(NS_SUCCEEDED(rv), "Fn failed");
--HG--
extra : rebase_source : 58788245021096efa8372a9dc1d597a611d45611
They are non-standard aliases for "DragEvent" and "KeyboardEvent" that
are not supported by any other UA, and we would like to drop support.
So first let's stop using them ourselves, so we can use telemetry to see
if any sites are using them.
MozReview-Commit-ID: ICC33ORa2st
This patch adds a MOZ_ASSERT. I'll try to pass it through try, and otherwise
turn it into a warning, I guess.
MozReview-Commit-ID: 9KZS6dh3wzw
--HG--
extra : rebase_source : 263cc55878fde3cea1fc0184cda4b3118e38d134
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
This patch makes GetBounds(), GetScreenBounds() and GetClientBounds() more
obviously infallible, like existing functions such as GetNaturalBounds() and
GetClientSize(). This results in clearer behaviour in nsCocoaWindow.mm if
Objective C exceptions occur. Along the way, the patch removes some useless
failure checks for these functions.
The patch also removes the NS_IMETHOD from GetRestoredBounds and makes that
function MOZ_MUST_USE.
First, when the first node causing text is invisible, OnQueryTextRect() still fails even with this patch. We shouldn't fix it in this bug because it's unusual case but this bug is very important especially for some web service using HTML editor like Gmail.
This patch fixes all cases when the start offset of queried range reaches the end of mRootContent.
1. When the last node causing text is a <br> element (either content <br> element or moz-<br> element), its frame is a placeholder for empty line. Therefore, this patch sets the rect to the frame rect.
2. When the last node causing text is a text node, the last frame generated for it represents its line (including empty line). Therefore, this patch sets the rect to the result of GetLineBreakerRectAfter().
3. When the last node causes a line breaker before it, the frame may be a placeholder for it (this is not usual case, when user types Enter key at the end of <p> element, <p><br></p> is generated by Gecko). In this case, this patch sets a possible caret rect which is guessed from the content box of the frame and its font height.
4. When there are no nodes causing text in mRootContent, this patch sets a possible caret rect like case #3.
MozReview-Commit-ID: FS9cWJQ39DK
--HG--
extra : rebase_source : cb2ea4cfb4c8d5c85a4dd7498aa11bd86b61c2ef
Similar to OnQueryTextRect(), OnQueryTextRectArray() should compute a line breaker's rect with the last character when it's the first character in queried range and not caused by <br> frame.
MozReview-Commit-ID: CGDHbcrc6zB
--HG--
extra : rebase_source : 7e7cad1aebc4b1c675360a1a1ff6e704d17c4e5c
When queried range starts with a block frame, we cannot compute proper line breaker's rect at its open tag only with the frame's rect because the proper rect should be at the end of previous text frame.
Therefore, this patch makes SetRangeFromFlatTextOffset() return the last text node found at scanning the range. Then, OnQueryTextRect() can compute the first line breaker's rect with it (if there is at least one text node).
However, if the last text node is hidden by CSS or something, this patch won't work. We need to do something in another bug for hidden frame's issue, though. But note that IME typically doesn't request hidden text's rect because neither selection nor composition string is in such range.
MozReview-Commit-ID: 2FFzNoubJ1y
--HG--
extra : rebase_source : b9c4af40b8747f19da8e55434d580e29322c9601
In plain text editor, moz-<br> element is appended for a placeholder of empty line when the text ends with a line breaker. Therefore, when we compute text rects, we need to handle it same as a normal <br> element even though it doesn't cause any text.
MozReview-Commit-ID: 4IXLafU6o0W
--HG--
extra : rebase_source : 5db9c70e3acd40e4f47f35fcf293702ce0fb0295
Although, this patch is pretty big and complicated, but I have no idea to separate this since this rewrites all over the OnQueryTextRect() with new utility methods which are implemented for OnQueryTextRectArray().
Currently, OnQueryTextRect() doesn't support line breaks before block level elements. Therefore, in HTML editors, eQueryTextRect may not work fine if the range includes open tags of block level elements. This causes odd positioning of IME's candidate window in non-e10s mode.
This implements ContentEventHandler::GetLastFrameHavingFlatTextInRange() which scans the given range from last to first. However, this hits wrong NS_ASSERTION() in nsContentIterator::Last(). mLast can be nullptr if there is no content but Init() returns NS_OK even in such case. I think that returning NS_OK is fine because it's not illegal case. Therefore this patch fixes the wrong assertion.
MozReview-Commit-ID: E6OnIA1eMou
--HG--
extra : rebase_source : e44114b6fb0024c2ab7f9101b12335de4b5cc4aa
When the loop in ContentEventHandler::OnQueryTextRectArray() reaches at the end of contents, it should append a caret rect at the end of the contents. That helps deciding popup position of IME when caret is at the end of the contents.
This patch guesses the caret rect with eQueryTextRect event (for avoiding the dependency of native caret position of eQueryCaretRect event handler).
MozReview-Commit-ID: 8cGeHpkzX9g
--HG--
extra : rebase_source : c7adc65ccf0fefa7cb1c3bd0b056dc04f8a85b3e
This is hack for returning better rect for a line breaker caused by non-<br> element. E.g., if a block frame causes a line break, after the last visible character is the best position, i.e., there is |<p>ABC</p><p>DEF</p>| and the caret is after "C", querying next character's rect should be computed with "C"'s rect, rather than computed with next <p> element's border rect.
MozReview-Commit-ID: 7nXt74GGpNf
--HG--
extra : rebase_source : 14807e98cc9a6be22e6168570a299abf0ecaf267
If it returns frames which don't cause text, the caller needs complicated loop. So, it should return only frames which causes some text.
MozReview-Commit-ID: 9gny0w1PUMa
--HG--
extra : rebase_source : 423c7b57355d659e1a5bd96dac35060cae38801c
If line breakers in a text node works as is, e.g., |white-space: pre;| is specified, we need to handle line breakers in text frames too.
This patch handles "\n" in text nodes same as line breakers caused by some elements.
MozReview-Commit-ID: JmXesusFxzR
--HG--
extra : rebase_source : dca28a6e4661eef3c8a102916c451e0f021bf6d5
If the query range starts middle of a line breaker, i.e., "\r[\n", ContentEventHandler::OnQueryTextRectArray() does not need to (in other words, should not) append same rect anymore.
This patch checks if the range starts middle of a line breaker and in such case, skip to append same rect.
MozReview-Commit-ID: H5gdtAakGcP
--HG--
extra : rebase_source : 3afaca4d6e9f09e2054c4a6bd876635cfef6c58c
Some elements causes a line break before itself. In such case, OnQueryTextRectArray() should append one or two rects for such line breakers.
This patch also implements GetLineBreakerRectBefore(). It computes line breaker rect for the given frame. Even if it's a <br> frame, we cannot use its rect because <br> frame height is computed with line height but we need text's height (i.e., font height) and both height and width are 0 if it's in quirks mode and in non-empty line. Therefore, this patch computes it with frame's baseline, font's max-ascent and max-descent.
Although, this patch computes a line breaker rect caused by a open tag of a block level element with block frame's rect. However, it shouldn't be used actually as far as possible. Following patches will kill the path to the hack.
MozReview-Commit-ID: 9cym04j9NH9
--HG--
extra : rebase_source : 3117d68f056dc69550a16f52adade82049ba8277
When eQueryTextRect's query range length is 0 (this may be caused by native IME's bug), it should return caret rect. Therefore, it should redirect such query events to OnQueryCaretRect(). Such IME must want caret rect in such case.
MozReview-Commit-ID: JaUwhw1Cn5G
--HG--
extra : rebase_source : aef43e028fdf19b1e4977ce0d73e3fd700793ba9
ContentEventHandler::OnQueryTextRect() is now too complicated. So, we shouldn't duplicate similar code in OnQueryCaretRect(). When it needs to guess a caret rect from a character rect, we shouldn't compute character rect by itself.
MozReview-Commit-ID: 5G4MzQJzmoV
--HG--
extra : rebase_source : 31f2ec578eeb2af82b8af2d938448eb42afd50ea
This can kill the duplicated code in a lot of places in ContentEventHandler.
MozReview-Commit-ID: BRpBkbXyeBs
--HG--
extra : rebase_source : 98021e68cd0150149e6417c5a8f91979f5baad76
Currently, ContentEventHandler::SetRangeFromFlatTextOffset() sets end point to before a line breaker when the end of queried range is between a set of native line breakers (i.e., "\r]\n" on Windows). This causes unexpected empty range (e.g., "[]\n") when it queries a text rect at [\r]\n.
Therefore, it should select an XP line breaker in such case (i.e., the range should be "[\n]" when it queries "[\r]\n" or "\r[\n]").
Note that we don't need to do anything at setting selection start because it's always aligned to before the line breaker.
MozReview-Commit-ID: 6ht8QNAhibY
--HG--
extra : rebase_source : b7933554c2a5bf51b8faabe3a96d006971510e0a
This patch makes the static methods members of ContentEventHandler because ContentEventHandler::NodePosition is useful for them.
* nsINode* AdjustTextRectNode(nsINode*, int32_t&) -> NodePosition GetNodeHavingFlatText(nsINode* int32_t)
* nsIFrame* GetFirstFrameInRange(nsRange*, int32_t&) -> FrameAndNodeOffset GetFirstFrameHavingFlatTextInRange(nsRange*)
So, this patch avoids unclear in/out arguments of them.
MozReview-Commit-ID: 7yWeIkRdGj
--HG--
extra : rebase_source : 635cec95ee9f3d73f619186925464ae17010e929
GetFirstFrameInRange() uses AdjustTextRectNode() which may return different node before retrieving the result frame. Therefore, the caller may need offset in the new node.
MozReview-Commit-ID: 2AQU5WfahT9
--HG--
extra : rebase_source : c753d34dc2691da2ec25c9f5a6fe17d67af24a70
Returning empty rects for eQueryTextRectArray causes each dispatcher needing to check every rect. It doesn't make sense especially compared with eQueryTextRect.
So, it should ensure that empty rect won't be returned to dispatchers.
MozReview-Commit-ID: CpMqqihzSDf
--HG--
extra : rebase_source : 0343e2eecf5e25043d260157cf4d8b0874e0ceb6
JS can create empty text nodes. Therefore, ContentEventHandler::GetLastFrameInRangeForTextRect() shouldn't use it for computing retrieving a text frame (Although, such text nodes shouldn't have primary frames).
MozReview-Commit-ID: EJAthEpNZNU
--HG--
extra : rebase_source : ccd05b46911077daa855a5c085839fd14aadc2ee
nextNodeOfRangeEnd is used for excluding unnecessary node for computing text rect. When aRange ends at start of a text node, the frames which are created for the text node shouldn't be used. However, if the end node of aRange is same as the start node of aRange, the node is not outside of aRange.
This could occur when it's called with empty range or there are some empty text nodes.
MozReview-Commit-ID: C1yCN5WrULe
--HG--
extra : rebase_source : 35d5b8feecd351bef29fe4af79a0f6f5bdad8bec
The createEvent() method supports only a fixed list of legacy event
types, and we would like to converge with other browsers on a list of
events to support. To this end, we want to know if any supported types
are unused so we can drop them.
MozReview-Commit-ID: 8uB1vepBCpi
Given that Blink has removed prefixed PointerLock API for quite a while
without receiving compatibility issue, I'd suggest we try dropping the
prefixed version directly.
We will either pref the prefixed API on if we see enough compatibility
issue, or remove the whole bunch of prefixed PointerLock API after the
unprefixed API reaches release channel without issues.
MozReview-Commit-ID: ACC69nqSBiH
--HG--
extra : source : 22791c53b6a94c3de4eb7f38823afce89b0419e4
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
This patch also renames:
EditorInputEventDispatcher -> mozilla::EditorInputEventDispatcher
And some variable names are renamed from aEditor or mEditor to aEditorBase or mEditorBase for making their types clearer.
MozReview-Commit-ID: 2FCXWpLMn8e
--HG--
rename : editor/libeditor/nsEditor.cpp => editor/libeditor/EditorBase.cpp
rename : editor/libeditor/nsEditor.h => editor/libeditor/EditorBase.h
I think that we can drop nsIMEUpdatePreference::DontNotifyChangesCausedByComposition(), i.e., nsIMEUpdatePreference::NOTIFY_CHANGES_CAUSED_BY_COMPOSITION because it's now used only by TSFTextStore but TSFTextStore ignores if SelectionChangeDataBase::mCausedByComposition or TextChangeDataBase::mCausedOnlyByComposition is true (for supporting async changes in e10s mode). So, only issue is, dropping the flag might cause increasing computing TextChangeData cost during composition in TSF mode. However, now, it's already enough fast and even if it'd cause performance regression, we could add a hack with TextComposition's offset information. Therefore, we don't need to worry about the performance regression so seriously.
MozReview-Commit-ID: HNT3G4isONj
--HG--
extra : rebase_source : 164231023aa2a17ceab94d92fb49ba0a00dab429
Currently, all widgets request selection change notifications to IMEContentObserver. Additionally, IMEContentObserver needs to listen selection changes for caching latest selection for eQuerySelectedText. Therefore, it doesn't make sense to keep defining nsIMEUpdatePreference::NOTIFY_SELECTION_CHANGE.
If widgets didn't need selection change notifications, they could just ignore the unnecessary notifications.
Note that all widgets don't need selection change notifications if a plugin has focus and IMEContentObserver cannot observe selection changes in the plugin. Therefore, if IMEContentObserver is initialized with a plugin, it shouldn't listen selection changes (and doesn't need to notify widgets of selection changes).
MozReview-Commit-ID: FOVFFgA2nOz
--HG--
extra : rebase_source : 3e16d5023835f99f82934e754d2e7db70474f9ee
It will use on ContentCache. Also, SetRangeFromFlatTextOffset issue will hanle on another bug.
MozReview-Commit-ID: 9Yu8bLlcZS5
--HG--
extra : rebase_source : c8eba70bdedf303b0fa649c1a609fe6120983e65
extra : histedit_source : 4189807b57ede13c1546e95052fcc298c8581d06
"ime-enabled-state-changed" notification was implemented for Android in bug 603848 but nobody currently observes this notification. Therefore, we can stop notify the observer service of this.
MozReview-Commit-ID: 3TNHf1xWo2l
--HG--
extra : rebase_source : 39c7e9e391cd6c9510785bca92020707714f4101
IMEContentObserver may have cache of normal selection. If it's available, IMEContentObserver should use it for computing absolute offset of WidgetQueryContentEvent whose mInput::mOffset is relative offset to selection.
This patch just improves the performance of such query.
MozReview-Commit-ID: KHLgCc2uQzs
--HG--
extra : rebase_source : 1367aee0aadb88258135690aa5a8591201129c27
Native IME handler may want to query content relative to start of selection (or composition if there is it). Additionally, in e10s mode, insertion point in actual content may be different from the cache in parent. Therefore, in some cases, it does make sense to query content with offset relative to start of selection or composition.
This patch implements it simply and only in non-e10s mode.
Additionally, this fixes a bug of nsQueryContentEventResult::GetOffset() which hasn't been accepted its calls even if the event message is valid (eQueryTextContent, eQueryTextRect and eQueryCaretRect).
MozReview-Commit-ID: 34I7vyTUAgO
--HG--
extra : rebase_source : d79ba0dc3e002f7691495ee1ff8bdb3854d8f6fe
TextComposition should update its composition start offset after every DOM event dispatch with first clause's selection type if there is composition string.
MozReview-Commit-ID: HFkePci1PhU
--HG--
extra : rebase_source : c7af075115505b52e48d8bbd5f2dd1d9001fe36e
Selection's focus and anchor node and offset are stored only for the last range. However, ContentEventHandler needs its first range. Therefore, ContentEventHandler shouldn't refer them if there are two or more selection ranges.
MozReview-Commit-ID: ACflFE3ZrOM
--HG--
extra : rebase_source : 9a2d1ef0e18a07881f77deff579830a4a0c97fc5
TextComposition needs to query first IME selection. Therefore, we need to add support to query special selection range with eQuerySelectedText.
First, WidgetQueryContentEvent::mInput should have mSelectionType which should be initialized with InitForQuerySelectedText() but unfortunately, there is no method for eQuerySelectedText. Therefore, this patch initializes WidgetQueryContentEvent::mInit::mSelectionType with SelectionType::eNormal in its constructor.
Next, ContentEventHandler needs to support to handle eQuerySelectedText with special selection types. However, we need to create 2 paths in some cases, one is for normal selection and the other is for special selections because there are no selection ranges may be usual case for special selections but not so for normal selection. Therefore, ContentEventHandler::InitCommon() becomes a little bit more complicated. ContentEventHandler::mSelection and ContentEventHandler::mFirstSelectedRange is initialized with the specified selection type but normal selection type is also necessary to compute the selection root since the selection root is computed from the first selected range which may not be anywhere if its selection type is not normal.
Finally, ContentEventHandler::OnQuerySelectedText() returns "there are no selections" as succeeded case in special selection type cases.
MozReview-Commit-ID: 9WzUx8b5piw
--HG--
extra : rebase_source : fb07b40748b594d36315f1fc21c0a02ff9f668bb
TextComposition queries selection start offset a lot of times. Therefore, for reducing the runtime cost, it should use IMEContentObserver if it's available or ContentEventHandler, otherwise.
MozReview-Commit-ID: 61GgQZDX2HP
--HG--
extra : rebase_source : 2080f77fa36e967e070495b11cc7b72e42e63fd1
When composition string hasn't been non-empty, insertion point of the composition string can be changed by a DOM event handler. E.g., compositionstart, first compositionupdate and first text. Therefore, TextComposition should update the composition start offset cache after every event dispatch.
MozReview-Commit-ID: FOPewPTRuCn
--HG--
extra : rebase_source : 95fbba8130a1d21e957cee305b3b2a433bfae56a
It's enough to store target clause offset from start of the composition and better to modify mCompositionStartOffset because when even if mCompositionStartOffset is changed, we don't need to modify the target clause offset.
This patch renames mCompositionTargetOffset to mTargetClauseOffsetInComposition.
MozReview-Commit-ID: 1wt2OTUUjkY
--HG--
extra : rebase_source : 1bb87899c6f2e374252aaa00535915d42c6bb29d
In all of the places touched by this patch, the smart pointer we're
appending is about to become unused, so simply .forget()'ing its
reference into the appropriate nsCOMArray works just fine.
Currently, when TextComposition tries to forcibly commit composition synchronously, it cancels the composition if there is only an ideographic space since legacy Chinese IMEs for Windows were used an ideographic space as a placeholder and shows actual composition string in its owning window (called reading window).
However, Japanese TIPs basically use composition to input an ideographic space. Unfortunately, this intentional input of an ideographic space is always canceled if an editor commits to composition at every input event in TSF mode because TSF cannot commit during a call of ITextStore::RequestLock(). Additionally, we will enable e10s mode, then, on all platforms, requesting commit composition is handled asynchronously.
Therefore, we should make the hack disabled in default settings now. If we'll find a way to distinguish if an ideographic space is a placeholder, we should recover this hack. Note that such input fields cannot handle such legacy IMEs, so, disabling the hack in default settings must be fine.
MozReview-Commit-ID: IdBcfBxeJum
--HG--
extra : rebase_source : 18ca5cd1083ade8813703cec05c020dc03f09f63
For sending NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED after the other change notifications which was caused by the user input, we need to use IMEContentObserver::IMENotificationSender because it sends the notifications when it's safe to do it.
This patch makes TextComposition use IMEContentObserver to send the notification. However, if there is no active IMEContentObserver, e.g., composition events are fired on unfocused window, TextComposition sends it by itself (same as current implementation).
If IMEContentObserver stops observing when it has pending NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED, it cannot send the notification (i.e., it is discarded completely in such case). However, in such case, IMEContentObserver sends NOTIFY_IME_OF_BLUR. So, anyway, native IME handler should treat the blur notification as it including NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED.
On the other hand, we're buggy if composition events are fired in non-active window. Even in such case, IMEContentObserver should be created for active editor in each document and it notifies IME of the changes. But this is out of the scope of this bug.
MozReview-Commit-ID: 7Q0ZsJTh4hX
--HG--
extra : rebase_source : 6417f991fa8c0fbe3f25b27bacf4257e5485aecc
It's not clear to me what NOTIFY_IME_OF_COMPOSITION_UPDATE means only from the name. For making the name clearer, this patch renames it to NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED and add some explanation to the definition.
MozReview-Commit-ID: 8ySYCNJ1Ytz
--HG--
extra : rebase_source : 3331b8f48e8b460c7f9b088064dcda9488f3403c
The Rebind() call in HandleEvent was attempting to be clever by sharing
string data with the error event's message. Unfortunately, we
eventually needed to pass the message out to JS, which required copying
the string for JS's purposes. Fortunately, we can attempt to be even
more clever by noticing whether the error event's message is already
allocated as a string buffer and sharing that, rather than just the raw
data. In the best case, the string buffer can be shared out to JS and
we avoid some needless copying.
Michael Layzell
Masayuki Nakano
Ho-Pang Hsu
Wes Kocher
Olli Pettay
Andrea Marchesini
Stone Shih
Jimmy Wang
Nicholas Nethercote
Thomas Wisniewski
Aryeh Gregor
Emilio Cobos Álvarez
Kan-Ru Chen
Ryan VanderMeulen
Andi-Bogdan Postelnicu
Xidorn Quan
Kartikaya Gupta
Sebastian Hengst
Ben Tian
Igor
Jan de Mooij
Mantaroh Yoshinaga
Bobby Holley
kearwood
Jonathan Kew
Kirk Steuber
Carsten "Tomcat" Book
Neil Deakin
isangelawu
Manish Goregaokar
Tom Tromey
Chris Peterson
Boris Zbarsky
Rex Lee
Nathan Froyd
Andreas Pehrson
Makoto Kato
Blake Kaplan
Jonathan Watt
Bob Owen
Gregor Wagner
Kannan Vijayan ext:(%2C%20Jonas%20Sicking%20%3Cjonas%40sicking.cc%3E)