There's a bit of a mobile/wasm munge with wasm considered a subset
of mobile in some places which should be unwound a bit, but for the
purposes of usable wasm by default, don't assume that wasm has an
onscreen keyboard so we don't lose keystrokes on assuming that
there will be an onscreen keyboard appearing when we lose and regain
focus.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I0baae0d414ce9aafd1c27d74bcdad2276d104ee5
L.Browser.touch is sometimes nice, but it's ultimately a flawed concept
to use it for input events. Using L.Browser.touch for input handicaps
people with mice if it's too liberal in what it classes as touchscreens,
and handicaps people with touchscreens if it's too conservative. There's
also no sweet spot: it's impossible to choose correctly if someone is
using both a touchscreen and a pointer device, as there's no right
option!
Previously many of our event handlers and some of our UI was gated
behind L.Browser.touch. This commit adds a new "window.touch" property
which is used instead. It has functions to help with event detection,
allowing you to easily make event handlers that work for only the input
devices they are designed for, without gating them behind feature
detection. This has the added bonus that - as you register all the
events - switching between a touchscreen and pointer is now not only
possible but already implemented!
For cases which don't have reasonable events to tag onto (e.g. the
teardrop for cursor movement) this commit adds "hasPrimaryTouchscreen"
and "hasAnyTouchscreen" which use the CSS media queries to detect if
there's a touchscreen attached to your device (either as the primary
input mechanism or at all). This works a lot more similarly to
L.Browser.mode, but being dynamically updated allows you to effectively
swich between touchscreen and not at-will. This still has all of the
disadvantages that L.Browser.touch did when used to register event
handlers, so my advice would be to avoid using it with events.
Signed-off-by: Skyler Grey <skyler.grey@collabora.com>
Change-Id: I9016fc15ad3ccb3664af348fdcdca006495b0778
It seems that datepicker control expects only a language input
in regional property (e.g. fr) instead of language-country (e.g. fr-FR).
Signed-off-by: Gabriel Masei <gabriel.masei@1and1.ro>
Change-Id: I7d5ac40cfa4a72cdc7862a8b4c4d14bdecad6c3b
At the moment, we try to detect whether the browser is running with a
touchscreen, however this is very imperfect. It's possible an integrator
may have more information about whether COOL is running on a device with
a touchscreen, so this ui_defaults option allows us to specify. Touch
mode binds inputs for touchscreen devices (long press for menu, pinch to
zoom, etc.) and does not bind the normal inputs (right click for menu,
etc.), so it's crucial to get it on all touch devices and no desktop
devices, as input is severely hampered if they are the wrong way round.
The option is called TouchscreenHint. Setting it to 'true' will enable
touchscreen mode, setting it to 'false' will disable touchscreen mode.
Leaving it undefined will keep our detection active.
This option must be set at page load so we can register the right
events at creation time. Therefore, ui_defaults is perfect as a method
to override this.
This is not a long-term solution. Instead, "The right thing" is to look
specifically for touch events and specifically for mouse events, rather
than using the default hammer.js behavior which is to look for both...
that should be an eventual followup to this. However, this was a lot
faster to implement and helps with the most pressing issue: not being
able to override our detection when it goes wrong.
Change-Id: Id28a156fe352fe6565ce6b472b7aa54d0869c48e
Signed-off-by: Skyler Grey <skyler.grey@collabora.com>
The new ui_defaults option OnscreenKeyboardHint is a tristate denoting
whether the device accessing Collabora Online has an onscreen keyboard
If unset, Collabora Online will do its best to guess. At time of
writing, this is the same as checking if the device is a mobile phone
or a tablet (note: only tablets which have the browser registered as a
"mobile" browser will be detected, e.g. the Microsoft Surface tablets
would not be detected)
If "true", Collabora will assume the device has an onscreen keyboard.
This will change when we trigger the keyboard, for example in calc if we
know of an onscreen keyboard we will not automatically focus a cell for
editing when it is selected, as this would pop up the keyboard.
If "false", Collabora will assume the device does not have an onscreen
keyboard, effectively doing the inverse of the "true" option above.
This is a followup to #7580 (0bf054c9a3)
which had Hint_OnscreenKeyboard and Hint_NoOnscreenKeyboard as
postmessage IDs to do the same thing.
Signed-off-by: Skyler Grey <skyler.grey@collabora.com>
Change-Id: I5deeb87a410c135d4cabda7ed24dc37e791800cd
matchMedia allows you to check matches for CSS media queries from
JavaScript. By checking if the primary pointer is 'course' we have a
pretty good shot at guessing that it's a touch device (mice, etc. are
'fine' instead). This expands our current touch detection so it detects
more screens, while making sure it doesn't detect devices which have a
touchscreen but also a mouse/touchpad/whatever. This non-detection is
important, because our touch support currently breaks things like the
rightclick menu on calc.
Touchscreen detection is useful for devices that are being used as touch
devices, because it enables some features like pinch-to-zoom and
hold-for-rightclick-menu which improve usability when you are using a
touchscreen. These are particularly important without a mouse.
Some devices are 2-in-1 laptops, which have a touchscreen and a
touchpad, but can be collapsed so only the touchscreen is active. These
devices will be detected as touch only when they are in their 'tablet'
form. *As we setup parts of the page differently, the page will need to
be refreshed if they change from tablet form to laptop form and
vice-versa*. Hopefully in the future we will make a followup so that
both input schemes can be enabled at the same time and extend this media
query detection to (any-pointer: course)
Signed-off-by: Skyler Grey <skyler.grey@collabora.com>
Change-Id: Ied4f61a1ffb06bd63359bc6d81c6a6c23436cc23
Before this change, panning a calc spreadsheet would cause the onscreen
keyboard to pop up when in tablet mode. Dismissing the keyboard would
not stop it from being popped up the next time you panned around. This
made it very difficult to pan around spreadsheets in calc without either
using an external keyboard, the mobile app or another device altogether.
This commit introduces a known regression: when you are on a tablet and
have a physical external keyboard, you could previously select the cell
and start typing. Now you must tap into the cell in the same way you
would if you have an onscreen keyboard. This matches the behavior on
mobile devices. I consider this regression a reasonable tradeoff, so
notwithstanding I believe this should be merged.
Additionally, this commit adds 2 POST messages, "Hint_OnscreenKeyboard"
and "Hint_NoOnscreenKeyboard". These can be used to override our guess
if you know more about whether the device has an onscreen keyboard than
we do.
Signed-off-by: Skyler Grey <skyler.grey@collabora.com>
Change-Id: I8f3683ccb9e57f0c4a5bf8e415f9aabef917dd78
This patch is a temporary workaround for fixing CI failures.
In fact on CI with a11y enabled cypress fails to load spreadsheets.
Signed-off-by: Marco Cecchetti <marco.cecchetti@collabora.com>
Change-Id: Ic661358cd47600ec9c3a329bef361b8087483017
The problem affects no-a11y case since the editable area is empty.
Since no copy/cut event is emitted, Clipboard.copy/cut is never
invoked. So we need to emit it manually.
To be honest it seems a Firefox bug. We need to check if they fix it
in later version.
Signed-off-by: Marco Cecchetti <marco.cecchetti@collabora.com>
Change-Id: I036414b5ffb5b35ff1ef1d7de1044e890832c673
On actual iPad (2048x1536 native, 1024x768 browser), in
landscape view in Safari, mobile phone view is shown in
online instead of tablet.
This reverts commit f1e9ee72fe.
Signed-off-by: Aron Budea <aron.budea@collabora.com>
Change-Id: I2cd4ba6cdcd616760c06c7db479e6d13be3d83b4
Added toggle button/menu entry for enable/disable accessibility support.
This ui feature is available for Online Writer only.
The button/menu entry is added only when accessibility is enabled at
server level.
That allows to enable/disable accessibility per view.
By default, the accessibility support is disabled.
Anyway the accessibility support state is saved to local storage
if available.
Signed-off-by: Marco Cecchetti <marco.cecchetti@collabora.com>
Change-Id: If5968a47f17922038b9da3d320cbed84ebb7688b
- also send 'App_LoadingStatus' postMessage with 'Loading_Progress'
Status to notify integrator
Signed-off-by: Rash419 <rashesh.padia@collabora.com>
Change-Id: Ie754955c53d4d361d8dfaf083f7734382954d3f9
We handle notification from core about currently focused paragraph:
content, caret position, text selection start/end.
Notifications are sent on any text changes, even when the text has
been modified in another view.
Moreover we can request such info to core at any time.
That allows AT software to read focused paragraph and selected text.
All that keeping editing still working.
A set of new cypress tests for checking clipboard content has been
developed.
failing cpp unit test:
- HTTPWSTest::testInactiveClient
'unexpected message' assertion was failing since an idle client can
receive an a11yfocuschanged message when the same paragraph has focus
in both view and the active view is editing the paragraph.
failing cypress tests:
desktop
- calc/autofilter_spec.js
- added more wait time before performing clickOnFirstCell
- impress/undo_redo_spec.js
- Repair Document was broken
- we need to select 'Hello world' in order to overwrite it
mobile
- impress/spellchecking_spec.js
- Apply suggestion
- better use selectTextOfShape instead of Ctrl-A
Signed-off-by: Marco Cecchetti <marco.cecchetti@collabora.com>
Change-Id: I070d390543fa66fe786c4a0661fa09f891b9883e
When we fail to download the localizaion javascript
file, for whatever reason, we end up failing to load
the document. This is far from ideal.
Instead, we simply log the error and move on.
The end result in such a failure scenario is that
the document loads, but the UI is only available
in English.
Change-Id: I5d29ff68870d0cd84d86658ccfd4e3185cc62562
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
window.screen.width/height returns the width/height
of the screen in CSS pixels. window.innerWidth/innerHeight
returns the interior width/height of the window in pixels.
This includes the width of the vertical scroll bar, if one is present.
That gives better result. eg: responsive mode
Signed-off-by: Gülşah Köse <gulsah.kose@collabora.com>
Change-Id: Ibecb9614224cb3bfd6d5d8dc9ad5febe6aa7673b
Interestingly, we've been sending the wrong length, resulting in
[ docbroker_003 ] ERR #-1: Missing final newline| wsd/ProxyProtocol.cpp:158
type errors, as we read that back in coolwsd.
Change-Id: Iff7d1d38b0ed3e99c1d6903e2663c4335a36aaa3
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
sheets[i].href can be null. Seen with proxy.php.
Signed-off-by: Andras Timar <andras.timar@collabora.com>
Change-Id: I3d774ace869d141973a92abab8ef9ac83e1e0018
We don't need the first one and we don't use the latter one.
Signed-off-by: Gökay Şatır <gokaysatir@collabora.com>
Change-Id: I1f48ff5487621781eb38dd8e4e8e2a389a3059d6
fetch route_token from indirectionurl and add them in wopisrc
parameter
Signed-off-by: Rash419 <rashesh.padia@collabora.com>
Change-Id: I6e724d0c59e12d4f7f6c125ec076e90d20b9b3c8
You now must pass --with-wasm-additional-files=<path> where path
contains a file called sample.docx.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I21e62feb6282833a5d60b31db26328eda63cdaea
(Note that the existence of a window.ThisIsTheEmscriptenApp property
is also a temporary hack; the eventual goal is for a one same Online
webpage to be able to switch automatically from server-based to
WASM-based and back based on connectivity to the server.)
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: Ia5e3f4008eaaf1543c08482418635dca0d3983e5
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Only once we have that working will we go back to having a COOL client
that on the fly can switch from a normal COOL server to using local
online and core code in WASM.
Note that the --with-wasm-fallback configure option now then
temporarily is a no-op, and the ENABLE_WASM_FALLBACK Automake
conditional and WASM_BUILDDIR Autoconf macro are not used anywhere.
Once we have something that barely works as a proof of concept, we can
go back to working towards what we really want.
(Yeah, yeah, I know that "temporary" solutions have a tendency to
become more permanent than you expect...)
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I2f01acd418686e672fd9d2e12cbbd688b128dfa5
