Drag and drop of images is dangerous in evince and too easy to perform

I notice that the new behaviour in evince is probably inspired by that of web browsers such as firefox. However, in firefox, I can't release an image OVER the firefox window to have it loaded. This prevents the problems above. To load an image by drag and drop in firefox I have to drag it over the address bar.

Just making your description more specific:
> I can't release an image OVER the firefox window to have it loaded.
is actually: "I can't release an image from the current document over the SAME firefox window to have it loaded."

If you drag an image from nautilus into the firefox window, it will be loaded. Also, if you drag an image from the current firefox document into the tab or URL bar, it will be loaded. Further, if you drag an image from a firefox window into another separate window, it will be loaded.

Thanks for pointing this out. Indeed, this would work well also in evince; OTOH, it is expected that dragging a file over evince loads it, so making each windows not be a target for its own drags would likely fix the bug.

Even if, I still dislike the behaviour also present in firefox to treat text and images differently on drag; I would consider clearer for the end user to select images when dragging, too but maybe I don't see obvious drawbacks.

The bug has been opened recently, got no duplicate and seems a rather small corner issue rather than an hundredpapercut design issue

It should have a trivial fix: do not accept drags from the same window. The consequences, for PDFs which are scanned documents, are that if you istinctively try to select text, or by mistake drag with your touchpad over the evince window, you may need to hard-reboot or wait until the system settles which can take a long time.

I do not know if bugs which should be trivial to fix and can give a bad impression to ordinary users is the aim of that tag (I did'nt put the tag here).

you seem to be the first user to run into that issue though so it seems to the not annoying many users

Could you add a pdf showing the issue there? How do you want to make the difference between select and dnd?

Not the first one, I keep running into it too. Nice functionality but gets
in the way more often when you do it by accident.

Works on any pdf that I've seen.

Sebastian: I think everyone runs into this, and they think it's their mistake to have dragged over the same window. Does it not happen to you? Something annoying that the system does and brings the user into fearing to do some action because it may lead to "mistakes" is an usability bug. E.g. when evince is opened on my laptop I noticed that I have an istinctive fear of touching my laptop's touchpad by mistake. This is what led me to report the bug in principle.

Here is a link to a sample document; it's not so heavy to swap out your gnome session but if you drag a page and release you'll notice it causes high system load for a while and brings up the same page of the document, thus causing the confusion I described above.

http://www.heldermann.de/R&E/RAE18/ctw07.pdf

> I think everyone runs into this, and they think it's their mistake to have dragged over the same window. Does it not happen to you?

No never happened and I've tried on a bunch of pdf I've locally but none has an image reacting to dnd, I'm also never using dnd if that's not to select text and when I select text I click on the text and not on some random image

> Something annoying that the system does

Could be, you are the first to complain about in 5 years of ubuntu though and dnd is something standard working on all computers, agreed that evince could be smart and not react on a dnd in the same document though, that is a valid concern and will probably be fixed but is still a low priority issue

doing a dnd on the example document uses 25% ressources for around 1 second on a 2 years old laptop configuration, I would not notice it without running top to see the processus usage

I've seen this as well - confused the hell out of me when it first happened and I'm not a novice. I have an application form that looks like page of text but is actually a page sized image, accidentally swiping the mouse pad caused evince to grey out (compiz) for a good minute before opening another evince (which also greyed out) that showed the same image but with a different window title (image-0).

Not a fan of this behaviour and I think it's a great fit for the papercut list as I've seen my partner wrestle with this oddity as well.

Sebastian: others are complaining as well; notice that it was not me who tagged this bug so I am definitely not the only one. Drag-drop happens frequently by mistake with touchpad, when touching it to move the pointer.

The bug has not been there in the last 5 years. It has been introduced in jaunty, I believe evince in hardy could not drag images at all. Thus nobody could have complained before jaunty.

As I said I consider it a good papercut because it should be trivial to fix. I tried this myself but do not know gtk or the gnome codebase, an ubuntu developer would probably have more experience.

I notice the other message now; the document I linked does not block your system, but there are heavier documents, I've seen it while browsing the web, so I can't provide you a proof. The bug is there anyways for the usability concern that I already told. As I didn't ask for the papercut myself I think I should refrain to comment more on that.

I am satisfied by the fact that this bug is considered to be fixed!

Il giorno gio, 11/06/2009 alle 18.03 +0000, NickSpencer ha scritto:
> I have an application form that looks
> like page of text but is actually a page sized image, accidentally
> swiping the mouse pad caused evince to grey out (compiz) for a good
> minute

NickSpencer, could you upload the application form for testing?

Could you add an example triggered the issue? It could make easier to work on the bug having an example to trigger the bug easily

I can't provide the application form (not in the public domain) but another
document that triggers similar behaviour (full page images) is attached

2009/6/11 Vincenzo Ciancia <email address hidden>

> Il giorno gio, 11/06/2009 alle 18.03 +0000, NickSpencer ha scritto:
> > I have an application form that looks
> > like page of text but is actually a page sized image, accidentally
> > swiping the mouse pad caused evince to grey out (compiz) for a good
> > minute
>
> NickSpencer, could you upload the application form for testing?
>
> --
> Drag and drop of images is dangerous in evince and too easy to perform
> https://bugs.launchpad.net/bugs/379403
> You received this bug notification because you are a direct subscriber
> of the bug.
>

the new example create a 1 second lag there, could it be that the issue is fixed on karmic?

No it also works the same way in jaunty; it may have been fixed there nevertheless, but the difficulty in finding a "heavy" pdf comes from the fact that not all pdfs have drag-able images. I have many scanned books that have high resolution graphics embedded. However, these pages are NOT draggable and it is not self-evident when drag can be done and when not.

This is also reported in the upstream bug. In my opinion, whatever the implementative reason for that is, this is extremely confusing. Perhaps drag and drop should be disabled entirely and first a working cut and paste implementation. However this does not belong to this bug report.

In the description of this bug I wrote that it causes three problems: possibility of heavy load, which remains unconfirmed for now at least, and the two usability issues of seeing the same page again, but "not being able to go to next page".

Please don't think I am over-estimating this; my 71 y.o. mother who learned to use ubuntu still has many troubles in understanding when a full-screen window is replaced by another one. For her, it seems like the _contents_ of the window have been replaced. Perhaps this happens because she does not look at all the screen but concentrates on the area where she is writing, thus she does not notice the titlebar changing.

This bug is a particularly pathological instance of the problem, as evince will spawn another window which looks the same, but ... does not have all the pages of the document. Then I understand that the user will close the evince window in frustration, discover the other window below, and without understanding what happened keep their work; but ubuntu will look worse for a bug which *should* have a few-liner patch.

still not sure to understand the issue, on karmic using those example there is a one second lag and no graphical nor document change, what is confusing?

reading the bug description again there is easy way to make a graphical distinction between real text and a bitmap showing text so people will always be confused in the second case when trying to select text which will not work, there is just no good way around this annoyance out of making impossible to select text at all in any document

This is indeed a corner issue, marking invalid as papercut.

Sebastian, I just ask for the *drop* to be disabled on the *same* window. This is surely feasible. Firefox does this. Of course it is nice that you can drag an image e.g. on the desktop. Then I will report the other bug on some graphics being able to be dragged, some other not.

This is certainly not unfeasible. Firefox implements this with html. Evince is a viewer and should do the same. Openoffice, which is an editor and not a viewer, instead allows you to drag on the same document, because it makes sense there. In evince it does not make sense. The current way evince does it is an implementation driven, not interface driven, feature.

So you say: "there is [NO?] easy way to make a graphical distinction between real text and a bitmap showing text so people will always be confused in the second case when trying to select text which will not work"

Indeed, precisely because there is no easy way, it is bad if we load a page of the document in front of the user when he drags from the same window. The user is confused by not being able to tell the difference in a second. When I first noticed this bug I was really confused myself, as others have confirmed above.

and: "there is just no good way around this annoyance out of making impossible to select text at all in any document"; no, there must be as firefox does that. Try for yourself, it will not accept drops of its own image, but it will allow you to select text and images, and also to drag an image over *another* firefox window.

Note in passing that evince already distinguishes drags over text from drags over an image and behaves differently: in the case of an image, it initiates a drag and drop operation, in the case of text, it initiates a selection. So if you ever wished to disable drag of graphics without disabling selection of text you could. In fact, evince in hardy did not drag images, but allowed to select text. However this paragraph is not aimed at convincing you to disable drag and drop of images. I am not asking for that.

The way to disable the *drop* is to modify the list of accepted *drops* on the window and has nothing to do with the "on drag initiate" code. Should really be a trivial patch, do you see this now?

If you agree that this can and should be fixed, I can try better in the source of evince as it is easy to find the relevant code; studying a bit of gtk can be good for me.

It does seem odd that evince deals with it in this way fullstop.

If we want to drag text on the same page, we have to select and then drag
otherwise nothing happens, whereas with an embedded image it can just be
dragged and will open up another version of evince with it inside.

Surely if we're matching behaviours then evince should not even be opening a
second instance containing an image but instead just storing the image in
the clipboard (or turn it into a png if dragged to a nautilus window) - or
perhaps, even opening it in eog?.

2009/6/12 Vincenzo Ciancia <email address hidden>

> Sebastian, I just ask for the *drop* to be disabled on the *same*
> window. This is surely feasible. Firefox does this. Of course it is nice
> that you can drag an image e.g. on the desktop. Then I will report the
> other bug on some graphics being able to be dragged, some other not.
>
> This is certainly not unfeasible. Firefox implements this with html.
> Evince is a viewer and should do the same. Openoffice, which is an
> editor and not a viewer, instead allows you to drag on the same
> document, because it makes sense there. In evince it does not make
> sense. The current way evince does it is an implementation driven, not
> interface driven, feature.
>
> So you say: "there is [NO?] easy way to make a graphical distinction
> between real text and a bitmap showing text so people will always be
> confused in the second case when trying to select text which will not
> work"
>
> Indeed, precisely because there is no easy way, it is bad if we load a
> page of the document in front of the user when he drags from the same
> window. The user is confused by not being able to tell the difference in
> a second. When I first noticed this bug I was really confused myself, as
> others have confirmed above.
>
> and: "there is just no good way around this annoyance out of making
> impossible to select text at all in any document"; no, there must be as
> firefox does that. Try for yourself, it will not accept drops of its own
> image, but it will allow you to select text and images, and also to drag
> an image over *another* firefox window.
>
> Note in passing that evince already distinguishes drags over text from
> drags over an image and behaves differently: in the case of an image, it
> initiates a drag and drop operation, in the case of text, it initiates a
> selection. So if you ever wished to disable drag of graphics without
> disabling selection of text you could. In fact, evince in hardy did not
> drag images, but allowed to select text. However this paragraph is not
> aimed at convincing you to disable drag and drop of images. I am not
> asking for that.
>
> The way to disable the *drop* is to modify the list of accepted *drops*
> on the window and has nothing to do with the "on drag initiate" code.
> Should really be a trivial patch, do you see this now?
>
> If you agree that this can and should be fixed, I can try better in the
> source of evince as it is easy to find the relevant code; studying a bit
> of gtk can be good for me.
>
> --
> Drag and drop of images is dangerous in evince and too easy to perform
> https://bugs.launchpad.net/bugs/379403
> You receiv...

I grepped the source of evince for the "drag-data-received" gtk signal and found nothing. Can some developer confirm that it is handled by external (gnome?) libraries? If this is the case, is it like evince itself can't decide to ignore a drop? If so do you know where to signal this bug properly?

Mat, let's keep this new. It has an easy fix, and I've seen it happen to many people (including myself many times), resulting in great confusion every time, so it's not a corner case.

David Siegel wrote:
> Mat, let's keep this new. It has an easy fix, and I've seen it happen to
> many people (including myself many times), resulting in great confusion
> every time, so it's not a corner case.
>
> ** Changed in: hundredpapercuts
> Status: Invalid => New
>
>
Fair enough. :)

I've run across (or rather into) the described, highly annoying, behaviour repeatedly
recently, and believe me, it can be regarded as a bug.

Thanks for reporting it.

bjd

Maybe I'm not understanding the code properly but I think this is solved in the git master branch.

from ev-window.c:

static void
ev_window_drag_data_received (GtkWidget *widget,
         GdkDragContext *context,
         gint x,
         gint y,
         GtkSelectionData *selection_data,
         guint info,
         guint time)

{
 EvWindow *window = EV_WINDOW (widget);
 gchar **uris;
 gint i = 0;
 GSList *uri_list = NULL;
 GtkWidget *source;

 source = gtk_drag_get_source_widget (context);
 if (source && widget == gtk_widget_get_toplevel (source)) {
  gtk_drag_finish (context, FALSE, FALSE, time);
  return;
 }

[....]

It seems like drag_data_received bails out if the source and the destination are the same.

I downloaded the evince source in karmic (which I am now testing) to try to paste the code above and... it's already there. In fact, the bug is fixed in karmic.

We did not see this as there where no comments on this on the upstream bug, but as devs where busier fixing it, that's only good news.

@David Siegel: perhaps there's room for another paper cut in the list then?

Vincenzo, that's great news, but it still counts as a paper cut fixed for Karmic, even if the fix happened upstream!