I am using an installation of Drupal 4.7.0 with Firefox 1.5.0.3 on Windows XP SP2. I have removed all extensions from Firefox, and I have enabled only a minimum of modules (story, help, page, upload) in the Drupal installation. I am using the bluemarine theme.

When attempting an Ajax-based upload, the following events occur:

0) On a new story node, enter test data in the title and body
1) Select a JPG image from my hard drive using the Browse button
2) Click the Attach button
3) A progress bar appears and quickly reaches 100% (the quickness is not necessarily a clue... it's a local web server and a 60k file, I'd expect it to be fast)
4) The progress bar is replaced with the attachment table, which shows the correct filename, and the correct file size in KB
5) Click the submit button to save the node
6) The node view page displays, but there are no attachments displayed (attachments are configured to be displayed by default)
7) Clicking edit again reveals the same form state as step 0 (obviously with the exception that the title and body content are filled in now)

If you replace step 2 above with clicking the submit button, the process works, but it uses traditional form upload methods.

In my attempts to debug, I have the following to contribute:

a) Line 679 of upload.module contains the Ajax response. There is no conditional to detect a failure in the process. 'status' = TRUE is hard-coded in the output.
b) It appears that the file is actually being uploaded, because the Ajax response contains the correct file size, the server-side code must have been aware of the file's contents.

CommentFileSizeAuthor
#15 favicon_state_0.txt658 bytesheine
#14 favicon_state.txt658 bytesheine
#8 favicon_patch_0.txt644 bytespwolanin

Comments

ADLongwell’s picture

ADLongwell commented

This isssue (34807) is potentially a duplicate, although it hasn't been touched for 5 weeks. I'd also note that when it occurs for me, I see no Javascript errors and no errors in my apache log.

ADLongwell’s picture

ADLongwell commented
Project: upload (simple) » Drupal core
Version: master » 4.7.0
Component: Code » upload.module

I have tested using FIrefox 1.0.8 on Ubuntu against the same Drupal instance. That browser works... it appears to not be a server-side error, but a client-side Javascript problem.

pwolanin’s picture

pwolanin commented

I had the same problem- due to the settings I put for the theme (though I think it's also a drupal bug):

http://drupal.org/node/64627

http://drupal.org/node/64650

To summarize: I unchecked the box for "use default shotcut icon" but did not supply another file instead. This resulted in a bad HTML header and the JS not loading in FF.

ADLongwell’s picture

ADLongwell commented
Title: Firefox 1.5.0.3 Cannot Use Ajax Uploads » Confirmed: This is a theme-related shortcut icon bug.

I had also unchecked the use default shortcut icon setting. Re-selecting the checkbox fixes the problem. I suppose I'll create a patch to better handle this error condition. I agree: this is a Drupal bug.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Title: Confirmed: This is a theme-related shortcut icon bug. » upload fails when default shortcut icon is unchecked

Good detective work - just changing title back - be aware that titles in bugs are different than comment subjects in forum posts.

ADLongwell’s picture

ADLongwell commented
Title: upload fails when default shortcut icon is unchecked » Ajax upload fails in Firefox when default shortcut icon is unchecked
Priority: Critical » Normal
Status: Active » Needs review

greggles: Thanks for the reminder.

I've discovered a patch that will work to fix this issue. However, I use Windows Eclipse and my own local SVN repository and I don't think I can generate a standardized .patch file. Here's the code change I propose:

In phptemplate.engine, change the if statement at line 147 from:

  /* Add favicon */
  if (theme_get_setting('toggle_favicon')) {
    drupal_set_html_head('<link rel="shortcut icon" href="'. check_url(theme_get_setting('favicon')) .'" type="image/x-icon" />');
  }

To:

  /* Add favicon */
  if (theme_get_setting('toggle_favicon') && check_url(theme_get_setting('favicon'))) {
    drupal_set_html_head('<link rel="shortcut icon" href="'. check_url(theme_get_setting('favicon')) .'" type="image/x-icon" />');
  }
pwolanin’s picture

pwolanin commented
Component: upload.module » theme system

Changing this to a "theme system" issue, and I'll mark my issue as duplicate.

pwolanin’s picture

pwolanin commented
StatusFileSize
new favicon_patch_0.txt644 bytes

Attached is a patch file based on the above. I changed is slightly so that there is only a single call to check_url(theme_get_setting('favicon')).

I tested this in Firefox 1.5, Drupal 4.7. Seems to completely solve the problem.

killes@www.drop.org’s picture

killes@www.drop.org commented
Version: 4.7.0 » x.y.z
Status: Needs review » Reviewed & tested by the community

applied to 4.7

dries’s picture

dries commented

I think this patch works for HEAD too.

I guess favicons can be hosted on a different server, so we can do a file_exists().

I wonder, though, what happens when you specify a valid path to an non-existant favicon.

Could someone try that?

dries’s picture

dries commented

Why am I asking? Because check_url() doesn't check whether the URL is valid. I just prepares the URL for being emitted to the client.

I wonder how this patch could fix the problem.

killes@www.drop.org’s picture

killes@www.drop.org commented

paths to non-existant favicons don't matter since the generated html is still valid. we might want to check if the file actually exists during form validation, though,

killes@www.drop.org’s picture

killes@www.drop.org commented
Status: Reviewed & tested by the community » Needs work

The real bug is probably elsewhere, maybe in theme_get_setting. The original test should have failed when the select box was deselected. I will leave the patch in 4.7 for now, HEAD needs a better solution, which mght then be backported.

heine’s picture

heine commented
Status: Needs work » Needs review
StatusFileSize
new favicon_state.txt658 bytes

Attached patch adds two else clauses to theme_get_setting leaving both logo and favicon in a consistent state.

heine’s picture

heine commented
StatusFileSize
new favicon_state_0.txt658 bytes

And now with normal path seperators (thanks killes)

pwolanin’s picture

pwolanin commented

@killes: I agree that the path to the file should be validated when the theme form is submitted, but I think a check at this point is also a good idea since the file could get moved, renamed, deleted, or be inacccessible.

@dries: if I have a chance today I'll test whether the uploads fail in FF if one provides a non-null, but invalid, URL for the favicon.

pwolanin’s picture

pwolanin commented

FYI, with my patch above (and thus probably without) FF still uploads with a non-empty but invalid URL.

Below, the page header with the nonexistant file "foo" specified as the favicon:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
  <title>more samples | Test Site</title>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<style type="text/css" media="all">@import "/misc/drupal.css";</style><script type="text/javascript" src="/misc/drupal.js"></script>
<script type="text/javascript" src="/misc/progress.js"></script>
<script type="text/javascript" src="/misc/upload.js"></script>
<script type="text/javascript" src="/misc/autocomplete.js"></script>

<script type="text/javascript" src="/misc/collapse.js"></script>
<script type="text/javascript" src="/misc/textarea.js"></script>
<link rel="shortcut icon" href="/foo" type="image/x-icon" />
  <style type="text/css" media="all">@import "/themes/test/style.css";</style>  <script type="text/javascript"> </script>
</head>
heine’s picture

heine commented

Upload doesn't fail when an invalid path is given. Only when the href attribute in LINK is empty, as killes wrote above. A check on form validation would be best, you'll see the 404 errors when you move the file and forget to update. Of course files usually do not move themselves.

heine’s picture

heine commented
Assigned: Unassigned » heine

Proper theme_settings validation is necessary (completely forgot about it).

Kjartan’s picture

Kjartan commented
Status: Needs review » Needs work

From the comments it looks like this patch still needs some work.

heine’s picture

heine commented
Assigned: heine » Unassigned
coreb’s picture

coreb commented
Version: x.y.z » 5.x-dev

Moving out of the "x.y.z" queue to a real queue.

pwolanin’s picture

pwolanin commented

Looks like this is still causing problems...

Ustas’s picture

Ustas commented

Yes, this problem is still actual: http://drupal.org/node/120798

ChrisKennedy’s picture

ChrisKennedy commented

http://drupal.org/node/125656 marked as a duplicate.

Crell’s picture

Crell commented

It's not just favicon, either. It looks like any image 404 at all will cause this problem. Marking this as dupe: http://drupal.org/node/125367

ceo3141’s picture

ceo3141 commented

I am having the same issue uploading the files; however, I have returned the theme to Blue Marine with the shortcut icon box checked, the favicon appears, but I still cannot upload files.

Here is my set up:
-Drupal 5.0
-commercial webhost with PHP 4.3.10
-enabled the content type (Event) for file upload [everything else about Events works fine]
-checked all the defaults in the File System and File Upload administration areas per the instructions for the Upload module in the handbook
-permissioned authenticated users to upload files under Access Control

When I try to upload files, either as the Administrator or as an Authenticated User, the moving bar shows up, looks like I have successfully uploaded, but then no files are attached. (No error message either.)

As I have tried implementing the solution in the forums (reinstituting the favicon), and it does not work, I am at a loss -- does anyone have any suggestions?

Many thanks.

Pushkar Gaikwad’s picture

Pushkar Gaikwad commented

I am having exact same problem, same bluemarine theeme, drupal 4.7. Let me try to apply the patch and see what happens

Pushkar Gaikwad’s picture

Pushkar Gaikwad commented

Ok, I solved the problem by install the patch at #15 of url http://drupal.org/node/65153 . The patch is http://drupal.org/files/issues/favicon_state_0.txt

Now the problem is, I can not see my favicon at all. I tried all possible combo of admin->themse (I am using bluemarine) but it seems they have been disabled by this patch. I am looking to use bannter module for which I really need upload.module with images working but I also want favicon to work :)

Any solution ?

mtolmacs’s picture

mtolmacs commented

I also having this issue with Drupal 5.1
Applying patches attached to this bug and see what happens.

Christefano-oldaccount’s picture

Christefano-oldaccount commented

The patch doesn't work for me. I decided instead to simply remove the "Attach" button (so the form looks more like the one in project_issue module) and added this to my style.css file:

input[value="Attach"] {
  display:none;
}

/* IE6 ignores display:none for buttons */
#attach-button {
  width:0px;
  height:0px;
  border-width:0px;
}

This isn't a permanent solution, of course, but at least the ineffective "Attach" button is gone. The problems I can see are (1) screenreaders will still see the "Attach" button and (2) multiple uploads are only possible by saving and editing the node over and over again.

mtolmacs’s picture

mtolmacs commented

I believe the original issue happens because the session in the asynchronous query checking overwrites the session array. I reported this bug to deal with it: http://drupal.org/node/152695

Anyway you can check if my assumption is right if you put some file log into the sess_open() and sess_close() function in includes/session.inc. It is enough to write out a SessionOpen and SessionClose row on the appropriate places. If the opens and closes nests, the here you go. Your session eventually gets overwritten randomly. If not, maybe the problem is elsewhere.

gracearoha’s picture

gracearoha commented

Has there been any solution to this? I am using FF 2.0, Drupal 5.2 and i cannot get the attach/upload to work with or without the icon checked. I also tried the style.css patch to remove the attach button but no go.

It was working fine when i was using FF 1.5 and Drupal 5.1.

Any ideas?

Christefano-oldaccount’s picture

Christefano-oldaccount commented

Please try the solution posted at http://drupal.org/node/162036#comment-277329 and let us know if it works for you.

gracearoha’s picture

gracearoha commented
Version: 5.x-dev » 5.2

i tried the solution posted by dtglmoon.

it doesn't seem to make a difference. I can upload the file, but the upload timer thingy keeps running and running.
if i watch the message in my browser footer i can see when the upload is really finished and then if i hit submit i see that the file has been attached. But how to get the upload timer thingy to stop running?

subspaceeddy’s picture

subspaceeddy commented

I can confirm a seemingly unrelated image 404 caused this problem for me, although oddly enough it worked OK if i was logged on as Administrator/user 1

*edit: this was supposed to be in reply to crell #26

dpearcefl’s picture

dpearcefl commented
Status: Needs work » Closed (won't fix)

Due to the age of the last comment on this issue and due to the fact that D5 is no longer supported, I am closing this issue.