In case an integration doesn't allow clipboard interaction via
<https://sdk.collaboraonline.com/docs/advanced_integration.html#allow-the-clipboard-permission-query>,
we end up in a situation where navigator.clipboard.write is not
undefined, but is broken.
By the time navigator.clipboard.write() fails, it's too late to fall
back to the old copy code, as the security context is already gone.
Fix the problem by improving the failure handling: show the popup to try
again copying, remember that navigator.clipboard.write() failed and
prefetch the text selection, so next time a copy is tried (via the
keyboard), the selection doesn't need re-creating. (Normally the
selection change would trigger the prefetch, so select->copy->copy-again
would still fail.)
Note that paste doesn't have a similar problem, since there we always
try the old paste code first, and only use the new paste code if the old
one fails.
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I12ea4810395970421000d213744d1838213c7a07
Sometimes an input we are focusing on is considered out of the viewport
by the browser. This is not always the case, and, even when it is, it's
not trivial to move it back in.
Instead, this change detects scrolling and re-scrolls the view to 0, 0.
Doing so is not without consequence, as there is a slight jitter before
we can scroll back, however this is substantially better than having the
controls off-the-page.
Signed-off-by: Skyler <skyler.grey@collabora.com>
Change-Id: Ie5003f9244ce1c0e8a183de5fdbcf3a880b13a13
Previously using the onscreen keyboard would shrink the visual viewport
while leaving the elements at the same size, meaning some of the content
had to be offscreen. As we scrolled the page to have the cursor in view,
this would move the notebook bar offscreen.
To avoid the possibility of the cursor leaving the screen or the bottom
toolbar being offscren, we can use the VisualViewport API to force the
logical viewport to have the same size as the visual one
This won't have an effect in iframes as the logical and visual viewport
in iframes are always the same, and we already scale to 100% height by
default anyway
Signed-off-by: Skyler <skyler.grey@collabora.com>
Change-Id: I07726bee8b61334f6a32e873ab2d5428fa60dca3
Trying to paste from the notebookbar in a setup which is not localhost
but uses http resulted in a JS exception:
> Clipboard.js:863 Uncaught TypeError: Cannot read properties of undefined (reading 'read')
We assumed that navigator.clipboard is always defined, but then its
'read' and 'write' properties may be undefined.
Fix the problem by abstracting this, and check for navigator.clipboard
as well in global.js.
Can be tested by disabling https in coolwsd.xml and changing localhost
to the real local IP in the make run URL.
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I1dab14e311066fa640dbba65dfcc35526a6886d7
One way for integrations to ask for dark mode is to set URL parameters.
This works for e.g. the language, but didn't work for dark mode.
There was already a parameter for this, but it was limited to Android.
Fix the problem by exposing the parameter for non-Android as well, and
also extend global.js to default to this, but keep the local storage as
an option to customize the setting if the user wants to.
Tested with 'make run', <input type=hidden> way may need more work on
top of this.
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I78c4115a8e337ef2b1ea9e498db2572965762bef
It was part of the removed Vereign document signing feature.
Signed-off-by: Andras Timar <andras.timar@collabora.com>
Change-Id: Ibe8a31102eaefcfba1898ad2f31226c24e12f330
Move debug toggle to after docloaded message
Move sidebar toggle even later than that
Signed-off-by: Neil Guertin <neil.guertin@collabora.com>
Change-Id: Ib72b5ef4c2c31f7707a384b2d819d5cde57a796d
The URLSearchParams() function was confused in the proxy.php
case, because the global.location.search contained two '?' marks,
like ?req=/browser/dist/cool.html?WOPISrc=...&lang=..&etc...
In the normal case the string started with ?WOPISrc=
Signed-off-by: Andras Timar <andras.timar@collabora.com>
Change-Id: I566935656be6622d698ea2ba3c949455877526f6
This reverts commit c69e14a5dd.
The above commits causes document loading in the iOS app to
always fail. Even the animated loading graphic never appears.
I don't know why removing that .js file causes this behavior,
but I did see the following in the trace messages in Xcode.
To Online: load url=null accessibilityState=false lang=en-US
It appears that the JS code is sending a null URL to load.
Signed-off-by: Patrick Luby <guibomacdev@gmail.com>
Change-Id: I7af391c4a4fb0d3d363b7023a27d4fcf92f7a4b5
like we do for the spelling setting, so we have the document in the
desired state early before any rendering, dropping the early full
document invalidations during initial setup
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I6b762c95fd4c00c7da04cf89f7bbeef4bc57375d
This fixes a regression where `framed.doc.html` wouldn't load.
Signed-off-by: Hubert Figuière <hub@collabora.com>
Change-Id: I57b4a617755be4615ec6ec734f6e084d57eaebce
We use this for the richdocumentscode case, but it is more
generally useful, this should be a pure re-factor.
Change-Id: I3a7f09d3da902a85dc2b362f7a160f07c90b97c6
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
This is an issue if we use encoded and decoded WOPISrc for the
same document when using load balancers like HAProxy. It should
be always encoded.
What we did:
cool.html:
http://haproxy.local:9980/browser/2a43eb3236/cool.html?WOPISrc=http%3A%2F%2Fsomewopisrcfileaddress&title=title
ws:
ws://haproxy.local:9980/cool/http%3A%2F%2Fsomewopisrcfileaddress/ws?WOPISrc=http://somewopisrcfileaddress&compat=/ws
These 2 were redirected to different nodes when balancing
was done based on WOPISrc
This is regression from commit a722687c11
browser: simplify getParameterByName
Signed-off-by: Szymon Kłos <szymon.klos@collabora.com>
Change-Id: I17f0c4551404cece0bb995205459f2b38e860795
Sets random language and launches debug mode,
turning on the Randomize User Settings tool
Signed-off-by: Neil Guertin <neil.guertin@collabora.com>
Change-Id: I5e06be624cd5383784ea640304980a82e76be229
The variable initialization does not depend on
the conditional M4 macro expansion.
Change-Id: I39f0079ea668768724e0ca3175070e66dc858b0b
Signed-off-by: Henry Castro <hcastro@collabora.com>
The iOS app add event listeners is not a
conditional M4 macro expansion, so
move into the global.js file.
Change-Id: I3adb767cc191a73f0d9197af692e22dd72c6ab46
Signed-off-by: Henry Castro <hcastro@collabora.com>
'logServer' to save logging data to server side.
Change-Id: I7e5fd0d0f3aefaade1f34b98f9004af2579ba2bd
Signed-off-by: Henry Castro <hcastro@collabora.com>
Use "fetch()" function to save logging client data
to server side.
Change-Id: I8b6a94b7ad7ae02ca00666759e3695867df4d372
Signed-off-by: Henry Castro <hcastro@collabora.com>
Make it more unified with "Office" color picker.
Use styling from jsdialog for color picker to match
all other ui components.
Unified with existing "Automatic" button for font color.
Signed-off-by: Szymon Kłos <szymon.klos@collabora.com>
Change-Id: I93d1031eaa7d3f3d52dc1812657eef20f4b88a82
- in case we will remember in localStorage old name which is no longer
present
- also add support dor DocumentColors when it will arrive
from core
Signed-off-by: Szymon Kłos <szymon.klos@collabora.com>
Change-Id: I9d4b5d91f424c8295da072836331e459d79c96d1
It will be possible to use "theme colors" then.
It requires core part: https://gerrit.libreoffice.org/c/core/+/161771
sc: announce theme colors with lok callback
Signed-off-by: Szymon Kłos <szymon.klos@collabora.com>
Change-Id: I74552027f57086910358e589ff3130655a236c53
This relies on core change I5e6c93c64af0d201a8ec045fea5546e189baca74
(https://gerrit.libreoffice.org/c/core/+/160313) as the logic to keep
the cell focused is from there.
Here we set the new option when there is an onscreen keyboard hint given
by ui_defaults or a postmessage. As ui_defaults are set at page load, we
need to wait to send our message until we're initializing everything
else to set our options. Additionally, we need to use the socket
directly rather than sending this through the map so that this bypasses
things like readonly mode
Signed-off-by: Skyler Grey <skyler.grey@collabora.com>
Change-Id: Ie6d80c0e1ebca607b9d705b673ab8008fae39260
Signed-off-by: Skyler Grey <skyler.grey@collabora.com>
Touch unification (b3bff28bede07a48cdecefcda14a6fc9da86e4bb, change ID
I9016fc15ad3ccb3664af348fdcdca006495b0778) was a rework of the input
system to better support touch devices, but unfortunately it caused some
fairly serious regressions. This commit fixes the following:
- Triple/Quadruple clicking was no longer recognized on non-touch
devices.
- There were some issues recognizing wrapped events
- Pens were considered to be touch devices, but this broke some
remote/virtual machine setups. It's possible that this change will
cause a regression for apple pencil users. I plan to get an Apple
pencil to test whether preventing pens from being touch devices breaks
the Apple pencil workflow instead
- manualDrag was taken to mean "is on a touch device". This is only
almost true, causing some input to be incorrectly ingnored when it was
not
- manualDrag and _manualDrag were confused. They affect different
things, and we now recognize this
Signed-off-by: Skyler Grey <skyler.grey@collabora.com>
Change-Id: Iab0d3bcca588eaed14469597868a9c4e2dcf8488
Signed-off-by: Skyler Grey <skyler.grey@collabora.com>
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
