This bug was fixed in the package webbrowser-app -
0.23+15.04.20141104.1-0ubuntu1
---------------
webbrowser-app (0.23+15.04.20141104.1-0ubuntu1) vivid; urgency=low
[ Ubuntu daily release ]
* New rebuild forced
[ Riccardo Padovani ]
* Added new upstream components to fit with design requests: multiple
selection in History, standard swipe-to-delete. (LP: #1351167)
[ Olivier Tilloy ]
* Do not use a custom scheme to trigger the error page, this won’t
work any longer as soon as oxide learns how to delegate unhandled
schemes (see https://launchpad.net/bugs/1384460). (LP: #1384460)
* Ensure that the 'dataLocation' context property is updated when the
application name changes. (LP: #1387754)
* Really honour the --fullscreen command-line switch. (LP: #1379766)
-- Ubuntu daily release <ps-jenk...@lists.canonical.com> Tue, 04 Nov 2014
15:22:49 +0000
** Changed in: webbrowser-app (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to webbrowser-app in Ubuntu.
https://bugs.launchpad.net/bugs/1387754
Title:
applicationName ignored in pure QML apps importing Ubuntu.Web
Status in Web Browser App:
In Progress
Status in “webbrowser-app” package in Ubuntu:
Fix Released
Bug description:
The dataPath for webviews is set in the plugin’s initializeEngine()
method, like so:
QDir
dataLocation(QStandardPaths::writableLocation(QStandardPaths::DataLocation));
engine->rootContext()->setContextProperty("dataLocation",
dataLocation.absolutePath());
This works well if the application has a C++ wrapper that sets the
application name before loading any QML, but it doesn’t work so well
for pure QML applications that import Ubuntu.Web: at the point in time
when they import the module, the app name most likely hasn’t been set
yet, and as a result the generic name set by qmlscene is used,
resulting in a dataPath that looks like "~/.local/share/Qt
Project/QtQmlViewer".
We don’t want to force applications to ship a thin C++ wrapper just to
work around this issue, so we will need to figure out a way to delay
the setting of dataLocation until the webview is actually
instantiated.
To manage notifications about this bug go to:
https://bugs.launchpad.net/webbrowser-app/+bug/1387754/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
