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

RESOLVED FIXED in Bugzilla 3.0

Status

()

RESOLVED FIXED
13 years ago
12 years ago

People

(Reporter: mkanat, Assigned: LpSolit)

Tracking

(Blocks: 1 bug)

2.13
Bugzilla 3.0
Bug Flags:
approval +
blocking3.0 +

Details

Attachments

(2 attachments)

(Reporter)

Description

13 years ago
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.
(Reporter)

Comment 1

13 years ago
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.
Severity: minor → normal
(Assignee)

Comment 2

13 years ago
(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
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).
*** Bug 303274 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

13 years ago
Blocks: 325501

Comment 5

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

Comment 6

12 years ago
(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

12 years ago
(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 
(Assignee)

Updated

12 years ago
Duplicate of this bug: 365072

Updated

12 years ago
Flags: blocking3.0?
Summary: Attachments don't work if you need to log in again → Attachments don't work if you need to log in again [ Undefined subroutine @ Fh::slice ]
(Assignee)

Updated

12 years ago
Duplicate of this bug: 365156
(Reporter)

Comment 10

12 years ago
This definitely won't go into 3.0--it's a major architectural change.
Flags: blocking3.0? → blocking3.0-
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.
Flags: blocking3.0- → blocking3.0+
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...
(Assignee)

Comment 13

12 years ago
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.
Target Milestone: --- → Bugzilla 3.0
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)....
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

12 years ago
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.
(Assignee)

Comment 17

12 years ago
Created attachment 250711 [details] [diff] [review]
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).
Assignee: attach-and-request → LpSolit
Status: NEW → ASSIGNED
Attachment #250711 - Flags: review?(justdave)
(Assignee)

Comment 18

12 years ago
Created attachment 250712 [details]
screenshot with patch v1 applied

Comment 19

12 years ago
might want to adjust the message "incomplete information in the form you just submitted" - it tends to sound like the user caused the error
Attachment #250711 - Flags: review?(justdave) → review+
Flags: approval+
(Assignee)

Comment 20

12 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.