this function doesn't work after I checked the checkbox. I tried on FF and IE.

Am I missing something here? Please advise. Thanks

Comments

vj0914’s picture

it's been 4 weeks, no one knows???

robmilne’s picture

Works for me in FF. Are you sure the attachment isn't an 'upload module' attachment rather than a 'webfm attachment'?

clintcar’s picture

I'm having a similar issue. Specifically a .PDF. It is done as a webfm attachment. Any resolution? Thanks!

drupaledmonk’s picture

Version: 6.x-2.10-rc4 » 6.x-2.11

It works fine in FF and chrome as it asks for download. Whereas in IE 7,8 it opens in the same window if it is a pdf and then gets stuck, the browsers back button(history) doesn't work to go back to the web file manager window. I can give a link to one of the website where I am facing problem, if I am not clear here. I am using 6.x.2.11

Anonymous’s picture

I think this is still open for debate. I am having this problem when dealing particularly with PDFs an txts. Regardless of the setting being set the browser (FF, chrome and IE 8) will load PDFs and txts in the same window. I tried hard coding some target _blank into the js and theme.inc, but no avail. Adobe reader is installed as well and I am using 6x-2.12.

Perhaps you, f4k1r do not or are running an OS other than Windows.

This is a problem for end users. What if they choose to look at a file and press back, the webfm manager resets its self and they have to re-navigate back to where they were.

drupaledmonk’s picture

Yes I use Ubuntu and this happens in FF, chrome also on a windows machine with adobe installed. Now when the user clicks on a pdf or for that matter any item in the file manager list needs to open up in a browser for me. In webfm.js at line 1720 I changed window.location to window.open and this pops up a new window rather than displaying the pdf in the same.

  if(as_file) {
    // Send download/open dialog
    //window.location = url;
     window.open(url);
  }

and at line 1747

    if(!sent) {
      window.open(url);
//      window.location = url;
    }
cgmonroe’s picture

Poked around on this and think I know what the problem is.... it's the way the target=_blank handling by various browsers.

If the "open in a new window" option is checked, the link to the attached file is correctly created with a target="_blank" attribute set and the href="file url" properly set.

This was a correct way to open a link in a new window.... until some new browser options came along. If I remember right, the combination of pop up spammers and the fact that _blank is being removed from HTML has lead to most newer browsers have an option to ignore _blank targets... unless the user turns it on. I also think that IE may change behaviors depending on the specified DOC type header.

This is also complicated by the fact that some browsers can display different mime type internally. (E.g. PDF plug-in or plain text files).

The trouble with the patch above is that only works with the main webfm pages and not the attachment list. It also forces all files to open a new window/tab.... probably need to come up with a more general set able option. But not sure how to preserve the attachment's ability to right click / save as... but still allow it to open in a new window. Grumble grumble grumble... pop up spammers... changing standards... grumble grumble grumbl...

drupaledmonk’s picture

How about a popup asking the user if he wants to open in a new tab else in the same window? The problem with opening in the same window is that the user navigates away from the website.

nhck’s picture

Status: Active » Closed (works as designed)

This Problem is browser related. IE9 can now handle it, so can FF.

Thank you for your time.