BQ E4.5 / M10 (OTA-10): Dekko && attachments PDF

Bug #1588485 reported by Matthias Apitz on 2016-06-02
This bug affects 26 people
Affects Status Importance Assigned to Milestone
Ubuntu Document Viewer App
Stefano Verzegnassi

Bug Description

I don't know since when, but for some time dekko + doc viewer does not
work correctly together. When I try to open a PDF attachment, dekko
stores this, for example, in:

~/.cache/com.ubuntu.docviewer/HubIncoming/9/dekko-attachment-p30853-QUOTEPLUS_DE_REL_PREF_31601429 2_2016-02-24.pdf

and asks me how to open it. I select doc viewer, but this is launched
with all files in ~/Documents and not with the attachment.

I raised this in the list and got the following reply:

Date: Thu, 2 Jun 2016 12:28:28 +0200
Message-ID: <email address hidden>
Subject: Re: [Ubuntu-phone] Dekko && attachments PDF
From: Stefano Verzegnassi <email address hidden>

Hi Matthias,

This is an issue in the Document Viewer. I have already prepared a fix
for this issue a month ago, before leaving the team.
No one is working on the DocViewer, so the merge proposal with the fix
is still waiting for a review. I guess you should wait for someone
from Canonical to have a look at it. ;)


Related branches

Changed in ubuntu-docviewer-app:
status: New → In Progress
assignee: nobody → Stefano Verzegnassi (verzegnassi-stefano)
importance: Undecided → Critical
Christian Dywan (kalikiana) wrote :

Is there a ContentHub bug about the problem with loading it asynchronously? By the looks of it the fix is to work-around that.

I guess ContentHub is not meant to be loaded asynchronously - at least, not yet.

There may be some issue in ContentHub, which should (could?) properly synchronize the communication between the two apps involved in the content transfer.
However, for now, it seems that DocViewer is not *fast enough* to catch the DBus signal sent from the service, so I would say there's just a bad usage of the ContentHub API inside DocViewer.

The code used here in DocViewer has been taken from address-book-app and, in this case, the async loading has been removed back in 2014.

By the way, loading ContentHub synchronously should not affect startup performance that much (DocViewer launches in ~2.2 seconds), therefore we can safely use this workaround.

Joachim Tuchel (jtuchel) wrote :

I found that hoing back to dekko and trying again leads to the PDF being offered by doc viewer. Not sure this is of any help, though

Fix committed into lp:ubuntu-docviewer-app at revision 353, scheduled for release in ubuntu-docviewer-app, milestone ww02-2016

Changed in ubuntu-docviewer-app:
status: In Progress → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers