problem:
till now we used values from DOM elements which were unreliable,
sometimes they are not discoverable due to nested iframs.
That threw some 404 due to incorrect theming path.
Signed-off-by: Pranam Lashkari <lpranam@collabora.com>
Change-Id: Ibc291ce9f64db799095e1edcb14c598bdd085de7
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
A new section about accessibility has been appended to coolwsd.xml
config file
Signed-off-by: Marco Cecchetti <marco.cecchetti@collabora.com>
Change-Id: I086abdf73646639283eb655ae60f200fb64e495a
In tabbed view when we open help or keyboard shortcts dialog
"button" style of cool-help.html overrides the button.ui-tab.notebookbar.
So all buttons (even in notebook bar) uses dialog buttons'
text-decoration: underline ans pad padding:0
Here we make the dialog's button style to specific that dialogs.
Signed-off-by: Gülşah Köse <gulsah.kose@collabora.com>
Change-Id: Iacaab42efa527fc5c6ada21fd007e4a352912b60
Mobile apps don't substitute these values so set them to zero length
strings.
Also, the iOS app sets the base text direction via the "dir" parameter
so add handling of that parameter in cool.html. TODO: check if the
Android and GTK apps need to implement the "dir" parameter to handle
RTL layout.
Signed-off-by: Patrick Luby <patrick.luby@collabora.com>
Change-Id: Ied8268ec256011281961ef610d53baeee0efe9cd
fetch route_token from indirectionurl and add them in wopisrc
parameter
Signed-off-by: Rash419 <rashesh.padia@collabora.com>
Change-Id: I6e724d0c59e12d4f7f6c125ec076e90d20b9b3c8
Now I hope things are initialised in the right order and the plumbing
gets set up so that messages are passed as expected. It seems to work
most of the time.
Main changes are:
- The online WASM executable is built using the -s MODULARIZE -s
EXPORT_NAME=createOnlineModule options. This means that the WASM
runtime is not automatically initialized and the main() function
is not automatically started. Only when the createOnlineModule()
function is called is that done. Calling exported C/C++ functions
is a little bit more complicated.
- Code to actually Base64-encode strings to be executed as
JavaScript when expected is now present in wasmapp.cpp. (After
being passed through the Base64ToArrayBuffer function on the JS
side.) Whether this is actually necessary is not fully clear, but
to keep the code similar to that in the GTK, iOS, and Android
apps, this is kept as such for now. It would probably work fine to
just directly create the ArrayBuffer in the C++ (using the EM_ASM
magic).
- The COOLWSD::run() function is now run in a separate thread so
that main() can return.
- The FakeWebSocket's onopen() function is now called from
innerMain(), where the HULLO message is sent. It remains a bit
unclear if this really is the ideal place.
In the mobile apps the HULLO message is sent and the onopen()
function is called in the window.socket.onopen() function in
global.js.
But note that despite that the WASM app and the mobile apps are
largely quite similarly constructed and the FakeSocket and
FakeWebSocket plumbing is the same, there is an important
difference. In a mobile app the C++ code is what runs first, and
that then loads the HTML page into WebKit, in which the JS
runs. In the WASM app it is the other way around. The web page is
naturaly the one that is loaded and the JS code then starts
running the C++ code as WASM.
Finally, note that the whole concept that there is a separate "WASM
app" is temporary.
What we eventually want to achieve is that the COOL webpage upon
loading will connect a COOL server. As it does currently. The COOL
server runs the online and core C++ code to load a document, and
renders document tiles and sends those to the client JS code to
dispay.
The new thing will be that, if enabled, in addition to the HTML and JS
resources, the client will also download the WASM code and data
resources. Also, the document and updates to it will be downloaded
while being edited so that a copy can be kept in client memory. But
the WASM code and the downloaded document will remain unused most of
the time. Only if the connection to the COOL server breaks will the JS
start running the WASM code and the JS will talk to online code
running locally as WASM instead of to a COOL server. Obviously there
are still lots of things hanging in the air here regarding how exactly
this will work.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: Ib1786a0b485d51797b0f2302d4296aa1ff9df5c1
Also, don't load online.js. It seems that it will be loaded into the
JS "web worker" for each thread automatically by
online.worker.js. (But hmm, what loads online.worker.js? I am probably
completely confused here. Probably getting rid of Qt things
(qtloader.js) and using only JS that Emscripten produces (modified if
necessary) will make things simpler to understand.)
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I050a20a553b7c0f6ebe9db0e7cb9cab2f9829f9e
Obviously just this is not a good reason to involve Qt, but we want
now initially to get something to even show up, so let's start by
using HTML and from the Qt-based WASM-LibreOffice. Let's see.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I7841fce8e5680a983cc00d516c3fca3a6747e9dc
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
There is no "Emscripten app", but a COOL client that additionally can
fall back to using in-client WASM code instead of a COOL server.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I86517c6a8f6e0397f6c466278c7be19db001e6d8
The WASM C++ bits (in wasm/wasmapp.cpp) will have to export functions
hande_cool_message(), handle_error_message(), and
handle_debug_message() to receive the calls from JS.
Change-Id: Ic7f2cffdeb4408a9f726ad70a8ceb8db372787dd
Signed-off-by: Tor Lillqvist <tml@collabora.com>
There is no "file server" in the mobile apps that would expand such
percent sequences. The generated cool.html file is used as is.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I046c23c13ade6195f3f4a8b395ede7c42fc46bd2
wopi host can add following input field to their html to override checkfileinfo, right now only
DownloadAsPostMessage is supported
<input name="checkfileinfo_override" value="DownloadAsPostMessage=true" type="hidden"/>
This can be usefull when same html is used to load collabora online in both desktop browser and mobile webview
Signed-off-by: Rash419 <rashesh.padia@collabora.com>
Change-Id: I8ff122f2824694d451724a832d992e08161fb448
now you can insert a mention just by starting to type with @
integrator needs to implement UI_Mention postmessage api endpoint on which
online will send request of initial character what user is typing on the basis of
that integrator should send the list of user using Action_Mention postmessage api call
object where each object contains { username: '<username>', profile: '<username profile link> }
for example you can check framed.doc.html
Signed-off-by: Rash419 <rashesh.padia@collabora.com>
Change-Id: I38387cd05f1654b0bdb2b4f31cbac633eece5722
Requested by several users and partners - defaults to off/un-changed.
When set it allows optional disabling of welcome/feedback when used
in a homely environment.
Also bump default max doc/conneciton limits in configure to 10k.
Change-Id: I3c917901e02445d45f6f86b554d47a60aa4e575d
Signed-off-by: Henry Castro <hcastro@collabora.com>
textarea focus makes firefox zoom in without
specifying viewport scale properties
Signed-off-by: Mert Tumer <mert.tumer@collabora.com>
Change-Id: Iea5c0e61af14dc8f05319570f84681ca2b76aed1
... and make Welcome dialog optional for COOL
config: add welome url parameter
Signed-off-by: Henry Castro <hcastro@collabora.com>
config: add feedback url parameter
Signed-off-by: Henry Castro <hcastro@collabora.com>
config: add infobar-url parameter
Signed-off-by: Henry Castro <hcastro@collabora.com>
welcome: fix unhandled exceptions
Signed-off-by: Henry Castro <hcastro@collabora.com>
welcome: preprocess welcome file
added welcome-message.html
Signed-off-by: Henry Castro <hcastro@collabora.com>
welcome: clean up code related to vex welcome
Signed-off-by: Henry Castro <hcastro@collabora.com>
--enable-welcome-message is not necessary, when we specify a welcome URL, then it is enabled, otherwise it's user configurable
Signed-off-by: Andras Timar <andras.timar@collabora.com>
remove the unused welcome config settings
Signed-off-by: Andras Timar <andras.timar@collabora.com>
remove unused define ENABLE_FEEDBACK
Signed-off-by: Andras Timar <andras.timar@collabora.com>
do not install/package fallback welcome dialog, when welcome feature is not configured
Signed-off-by: Andras Timar <andras.timar@collabora.com>
remove welcome-message.html
Signed-off-by: Andras Timar <andras.timar@collabora.com>
Change-Id: I20aa6220362018b63aaebd114b2b661561823fbb
use empty string in mobile app since it is not used
Signed-off-by: Mert Tumer <mert.tumer@collabora.com>
Change-Id: I699c348c01ad06b7e720499a615e2c9a27bbf630
