109054 - If auth fails on create new attachment, no Bugzilla header is displayed

Status: RESOLVED WORKSFORME

(Bugzilla :: Attachments & Requests, defect, P1)

Description

[Christopher Aillon (sabbatical, not receiving bugmail)]

Go to a create new attachment page and turn off cookies and try to upload an
attachment.  See also bug 109048.

You get a yucky text/plain message that says this and only this:

The name <TT></TT> is not a valid username.  Either you
misspelled it, or the person has not registered for a
Bugzilla account.
<P>Please hit the <B>Back</B> button and try again.

Comment 1

[Bradley Baetz (:bbaetz)]

Dupe of bug 109048, it looks like.

*** This bug has been marked as a duplicate of 109048 ***

Comment 2

[Christopher Aillon (sabbatical, not receiving bugmail)]

Re-opening.  Bug 109048 (which I'm aware of) is about WHY that happens.  The
reporter of that bug got that page because something screwed up, either no
cookies or something. 

This is about what happens after 109048 happens.

Comment 3

[Gervase Markham [:gerv]]

This is hard to fix. 

sub DBNameToIdAndCheck() does not know whether the HTML headers are started, or
finished, or midway through when it is called, which makes error reporting
difficult. To date, it has always added an extra \n to finish the headers, but
that means you can't use a canned error function like DisplayError() - because
if the headers weren't started (as in this case), then there are no headers and
the HTML from DisplayError (which generates its own header) gets displayed as
plain text.
<sigh>.

Gerv

Comment 4

[Dave Miller [:justdave]]

ping...

Comment 5

[Myk Melez [:myk] [@mykmelez]]

I can't reproduce this.  Reporter, can you try on the tip and see if it still
happens?

Comment 6

[Christopher Aillon (sabbatical, not receiving bugmail)]

Assignee, no I can't reproduce this on the tip.  This got masked by the fix for
bug 109048.

What this bug is about is that in certain situations (back out bug 109048 for
the example mentioned in this bug), you get a text/plain message as outlined in
comment #0 that is not informative at all.  See sub DBNameToIdAndCheck() @
http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/globals.pl#943

If we enter the else loop there, and no Bugzilla headers stuff have been sent to
the browser yet, we just get everything in plain text.  In Moz that means the
HTML is shown.  Furthermore, if $name is an empty string, then "The name
<TT></TT>" ... is not at all useful.  So when we enter that code, we need to
send headers if they've been displayed already, or only call that function after
headers are displayed (and send the footer as well) and check to see if $name
has been supplied.  If not, it doesn't make sense to display the message we
currently do.  A different message (or a more generic one for all cases) is
preferred.

Comment 7

[Dave Miller [:justdave]]

Since the only way we know how to reproduce this is getting masked at the
moment, so you won't really see this that often, I'm pushing this off.  We have
bigger things to worry about for 2.16.  If this happens to get fixed by the
templatization, set dependencies appropriately and move it back.

Comment 8

[Matthew Tuck [:CodeMachine]]

This should have been fixed during 2.16 templatisation, so moving there so
someone can test it.

Comment 9

[Gervase Markham [:gerv]]

DBNameToIDAndCheck now uses a proper error reporting function.

Gerv

Comment 10

[Dave Miller [:justdave]]

clearing target milestone on invalid/duplicate/worksforme/wontfix bugs so
they'll show up as untriaged if they get reopened.