Usability: "Upload" links should open in another window

Promoting to usability. Feature requests have to go to the current development version.

I'm not sure where I stand on this issue.

Target blank is not allowed in W3C guidelines? Have you found anyone else struggling with this?

The title is a bit confusing. Do you mean upload or download?

Anyway: -1. "Don't touch my browser." Users who would like to open a new window can choose to do so themselves. Don't force them.

So is it still a problem? Is it a problem many people would encounter, or is it something specific that has a workaround that might even be better? It is definitly an issue, but I am not sure wheter its a global browser interaction issue or Drupal specific, as gaele said we shouldnt be touching people's browser.

HTML 5, arn't most of us still at HTML 4? I am not in that loop so I dont know.

I just ran into this in 6.x and agree it is a big issue. if an image is attached to a node the back button should not be required to get back into drupal. there should be options for document handling that would normally be handled by the browser, especially images. with other file types like pdf and doc it's assumed the user has handlers set up, but images are problematic because a lot of users expect images to appear in a pop-up window with a "back" or "close" link. admins should be able to specify how the image opens.

"Back" and "Close" links just replicate browser functionality. And though it is a bit inconvenient, we can be sure that people know how to use the browsers 'Back' button, it's still the most used one by far.

I can see how it is weird that you lose the Drupal context if you click an attached image, but it is an attachment afterall. I don't think this is a Drupal issue, and I don't think it's the core upload module's job to specify mime-type specific behaviour.

I'm just not sure if it's a 'by design' or a 'won't fix'!

Is this problem not solved with 'inline' module which shows the attached image in the content ?

Ideally there can be a small button ( showing external window icon ) so that the attached image can be opened in a separate window.
Keeping backlinks to the actual content will not be = touching people's browser.

The usual happening as in email with image attachments is that attachments are downloaded rather than being shown in the browser without any link to content.

inline image display isn't always the right solution. we have a couple of pages of advertising image files for web and print and for the print ones it would be better to open in another window or (even better) force a download dialog to open.

we also use the inline assist module for inline display in blog posts and our gallery, it's just not practical for everything.

that most users, those who do not know much of anything, will expect to be able to add images to their content without having to go through hoops.

If, by users, you mean the end-users or surfers to your site, they will face no problem if 'inline' is installed.
Drupal is modular - so, even 'forum' 'blog' etc are all modules. Inline is just another module which you need with image and upload.

Way back in 1996 almost all forum scripts were text oriented with attachments perhaps ,and one could show images directly if html was enabled and allowed. Same with Drupal here also.

Regarding attachment, it would be good indeed if a separate button by the side of attachment
is provided that opens the image in a new window OR if it opens in the same window then back links to the main page would indeed be user-freindly ( the browser has back buttons and the user knows to use that BUT then why do we have breadcrumbs at all :) )

With either inline OR http://drupal.org/project/imagefield the endusers or site users can easily uplaod image and see them withouy any hassles. Inline ( along with imagecache) also gives the advantage of scaling down a hugely oversize image that breaks the (width) site design.

Trust me, we don't want to repeat the 'images in core" discussion here :) Neither is this the place to discuss which contrib module you are using. Thanks all for your input, though.

You are somewhat right :)
There has been indeed long debates w.r.t this.

Maybe the average Joe should download one of those profiles or Acquia - probably one or more of these packages comes configured with image and all so that one need not fiddle much with installing modules and settings.

While I agree with the last posts, the title of this still makes me ask the question - why not give people the choice? I could be veering off topic and in which case let me know but I would suggest that for usability, the upload module has admin settings either globally, or for each content type (or even for each node with right permissions?) that allows:

Open file in same window
Open file in new window
Force file download

This last one for me is also important in that PDF's (for example) opening in the browser window is something I regularly get complaints about as most people want to download them and are too lazy or naive to know that they can right click and save as.

Just my opinion, to give more choice on this matter would enhance an admin's ability to deliver content in the best way.

I couldn't agree more - NOT having such (default settable) options when you attach a file seems absolutely crazy to me.

When was the last time you put an attachment link onto an HTML page and DID NOT set target="_blank" ???

Right, enough moaning - after some searching, I found that in fact I could override the the ..._upload_attachments($files) hook and, having then looked into l() api function, that this (look at the emboldened bit) should do it in Drupal 6.x ...

function [my_theme]_upload_attachments($files) {
$header = array(t('Attachment'), t('Size'));
$rows = array();
foreach ($files as $file) {
$file = (object)$file;
if ($file->list && empty($file->remove)) {
$href = file_create_url($file->filepath);
$text = $file->description ? $file->description : $file->filename;
$rows[] = array(l($text, $href, array('attributes' => array('target' => '_blank'))), format_size($file->filesize));
}
}
if (count($rows)) {
return theme('table', $header, $rows, array('id' => 'attachments'));
}
}

... should do the trick.

Does it?

Does it Hell, the actual link generated by the module STILL doesn't include the target='_blank' attribute !!! Aaaaaaagh!, What AM I doing wrong?

What is one to do?

Nick

I'm having the same issue... not sure if yours is caused by the same thing as mine, but I think I'm narrowing in on my problem...

I am generating a list of uploaded documents using a view (drupal 6, views2)

If I browse directly to the node containing the upload attachment, the link renders per what I have in template.php...

If I let the view render the link, it forces the link to be rendered the default way.

This appears to be generated in the file "modules/views/modules/upload/views_handler_field_upload_fid.inc"

  function render_link($data, $values) {
    if (!empty($this->options['link_to_file']) && $data !== NULL && $data !== '') {
      return l($data, file_create_url($values->filepath), array('html' => TRUE));
    }
    else {
      return $data;
    }
  }

If I hack this directly in the module to look like this:

  function render_link($data, $values) {
    if (!empty($this->options['link_to_file']) && $data !== NULL && $data !== '') {
      return l($data, file_create_url($values->filepath), array('attributes' => array('target' => '_blank'))  );
    }
    else {
      return $data;
    }
  }

Then the files in my view open in a new window as expected. However, I know that this is not the proper way to override a function... I imagine that I'm supposed to put something in my template.php to do this... can anyone help out there?