299405 - Attachments don't work if you need to log in again [ Undefined subroutine @ Fh::slice ]

Status: RESOLVED FIXED

(Bugzilla :: Attachments & Requests, defect)

Description

[Max Kanat-Alexander]

This is 1/2 of the original problem described in bug 87404.

Basically, if you lose your login (or you don't have cookies enabled) when
creating an attachment, the file is lost when you have to log in again, spitting
a somewhat cryptic error message.

Comment 1

[Max Kanat-Alexander]

FWIW, I think the solution described in bug 87404 comment 21 is probably the
best way to go with this, if we can make it work.

Comment 2

[Frédéric Buclin]

(In reply to comment #1)
> FWIW, I think the solution described in bug 87404 comment 21 is probably the
> best way to go with this, if we can make it work.

Read comment 57 on how to do this

Comment 3

[Dave Miller [:justdave]]

I'm still partial to the solution in bug 87404 comment 30.

Our current solution for user matching (what this got split off of) is
less-than-optimal also, since it discards the requestee field if a match has to
be made, and that would let us put that back without requiring AJAX for it to
function (although that would certainly be cool, too).

Comment 4

[Teemu Mannermaa (:wicked)]

*** Bug 303274 has been marked as a duplicate of this bug. ***

Comment 5

[Olav Vitters]

*** Bug 326451 has been marked as a duplicate of this bug. ***

Comment 6

[Denis Roy]

(In reply to comment #0)
> spitting
> a somewhat cryptic error message.

In the interim, could a less cryptic message be spat to the user, to minimize e-mails to the sysadmins?

Comment 7

[Olivier Thereaux]

(In reply to comment #0)
> spitting a somewhat cryptic error message.

(making sure that people can find this bug through search engines)
The cryptic message in question is usually something like:

  undef error - Undefined subroutine Fh::slice at 
  data/template/template/en/default/global/hidden-fields.html.tmpl 

Comment 10

[Max Kanat-Alexander]

This definitely won't go into 3.0--it's a major architectural change.

Comment 11

[Dave Miller [:justdave]]

We need to fix this so the error doesn't happen (and give an error explaining what happened instead of choking on it) at a minimum before 3.0.  Fixing it the right way can be an architectural change.

Comment 12

[Dave Miller [:justdave]]

For reference I get two or three emails a week on bugzilla-admin reporting this error on bmo, even after the upgrade.  I'd gotten the impression somewhere that the filehandle leaking into the hidden fields template had gotten resolved already, but apparently it hasn't.  I thought we dealt with this by discarding the flag usermatches and telling the user they'll have to redo their requests...

Comment 13

[Frédéric Buclin]

This has nothing to do with flags. When you have to log in, you get an intermediate page, and the attachment cannot be saved as a hidden field.

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This is really about having to show an intermediate page of any sort (rather than needing to log in) when adding an attachment, right?  

I was certainly logged-in when I encountered the situation I filed bug 365156 about (and the issue there was needing username matching on the cc field, not any attachment-related field per se)....

Comment 15

[Matthew (lilmatt) Willis]

This doesn't really sound like the same bug to me, but reed asked me to log it here.

I just tried to create a new bug and attach a patch in one step.

I got the following error message:
URL: https://bugzilla.mozilla.org/post_bug.cgi
undef error - Undefined subroutine Fh::slice at /opt/webtools/bugzilla/data/template//opt/webtools/bugzilla/template/en/default/global/hidden-fields.html.tmpl line 58 

Note the duplicate path in the error message.

I was logged in when I attempted to file the bug, and the footer below the error message confirms that I'm still logged in.

Comment 16

[Wayne Mery (:wsmwk)]

confirming everything in comment 15.

I suspect cc caused it - I had cc entries that were not full addresses and should have gotten bz address completion screen.  So Smokey might be right about "any intermediate" screen.

Comment 17

[Frédéric Buclin]

Attachment: patch, v1

As per my discussion with justdave on IRC, we will ask the user to re-attach the file in the intermediate page, explaining why he has to do so. This is an intermediate solution between throwing an error and having the attachment stored in a temporary table in the DB (which would involve a DB schema change, which we want to avoid so close to 3.0 RC1).

Comment 18

[Frédéric Buclin]

Attachment: screenshot with patch v1 applied

Comment 19

[Wayne Mery (:wsmwk)]

might want to adjust the message "incomplete information in the form you just submitted" - it tends to sound like the user caused the error

Comment 20

[Frédéric Buclin]

Checking in skins/standard/global.css;
/cvsroot/mozilla/webtools/bugzilla/skins/standard/global.css,v  <--  global.css
new revision: 1.30; previous revision: 1.29
done
Checking in template/en/default/account/auth/login.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/account/auth/login.html.tmpl,v  <--  login.html.tmpl
new revision: 1.18; previous revision: 1.17
done
Checking in template/en/default/bug/create/confirm-create-dupe.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/create/confirm-create-dupe.html.tmpl,v  <--  confirm-create-dupe.html.tmpl
new revision: 1.3; previous revision: 1.2
done
Checking in template/en/default/global/confirm-user-match.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/confirm-user-match.html.tmpl,v  <--  confirm-user-match.html.tmpl
new revision: 1.16; previous revision: 1.15
done
Checking in template/en/default/global/hidden-fields.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/hidden-fields.html.tmpl,v  <--  hidden-fields.html.tmpl
new revision: 1.10; previous revision: 1.9
done