Closed Bug 20092 (knob) Opened 25 years ago Closed 21 years ago

bugzilla form checking not robust enough

Categories

(Bugzilla :: Bugzilla-General, defect, P2)

Product:
Bugzilla
Component:
Bugzilla-General
Version:
2.10
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Bugzilla 2.18

People

(Reporter: endico, Assigned: justdave)

References

(Depends on 1 open bug)

Details

Attachments

(3 files, 2 obsolete files)

HTML source of the page I was commenting on when error occurred
21.11 KB, text/plain
Details
Take 3 -- don't overwrite the actual value
1.38 KB, patch
justdave
: review-
Details | Diff | Splinter Review
the bug & comment I couldn´t submit in comment #169
35.37 KB, text/html
Details 
We suspect mozilla of triggering corruption to bugzilla's database.

We think the fact that mozilla doesn't support cookies is causing
bugs to be entered with NULL reporters. We've also noticed bugs
showing up in the Architecture component when they shouldn't and
suspect that updating bugs causes values in 'select' form items
to change.

We're asking people to stop entering or updating real bugs with
mozilla until this can be investigated further and bugzilla is
bulletproofed.
There was one known bug that I know caused such corruption, but it's
been fixed:

Bug 17519 was fixed on Nov. 11 (and it started in late October).  Was
M11 released without the fix?  (I haven't actually tried the milestone
build.)  This would cause SELECT corruption (things changing to the first item
in the select) in builds leading up to M11 (hopefully not the milestone release
itself).

Mozilla does support cookies.  That's not the problem.

Do you have any idea who filed the bugs with NULL reporters so you can ask them
about what they did?

Since bug 17519 was fixed (and before it started), I've been using Mozilla to
work with bugzilla quite reliably (both entering and modifying bugs),
and tracking almost all my changes in the email diffs to watch for bugs.  I
haven't seen any of these problems.

Could you post some example bug numbers of corrupted bugs to this report?
Thanks for the pointer to 17519. I definately saw evidence of this type
of corruption. Was this bug on terry's radar? Was any work done to search
for corrupted data? Its worth noting that the first field in the resolution
dropdown is 'fixed' so maybe some bugs are marked fixed that shouldn't be.

There's a new product called "architecture" which now replaces 'browser'
as the first product in the list. Yesterday we noticed bugs assigned to
the architecture product that shouldn't have been.Bugs 19914 and 19988,
were submitted november 23. They both have shaver as the qa contact which
indicates that the bug was originally set to Architecture/All (both first
in their respective lists)  These are probably user input errors because
the product isn't initially chosen from a dropdown. Still, its worth looking
at.

Bug 19881 also seems to have been entered wrong. Brendan and I found it
assigned to Architecture/Misc with the qa contact set (appropriately) to
nobody. It seems odd that mjudge would have done this by accident but maybe.

So far, no proof that anything bad has happened but these look suspicious.
There's no way to set the product of a new bug without the user actually
clicking on one of the product links on enter_bug.cgi is there? It looks
fishy that Architecture is now the first product alphabetically and that
inappropriate bugs are showing up here, however people are probably just
clicking on the wrong link.

Bug 20015 is a real problem. Continuing discussion in a new comment.
oops, i meant to say bug 19981, not 19881
Simon created a tesst bug 20015 using Mozilla. Brendan and I found it in the
Architecture product with the reporter listed as "__UNKNOWN__". Looking at the
bug activity report http://bugzilla.mozilla.org/show_activity.cgi?id=20015,
it looks like the act of closing the bug changed the component from
browser-general to editor, the product from blank to architecture, and the
version from "other" to "5.0".

The reason I suspect mozilla's cookies of corrupting the reporter field is
that when a new bug is entered the reporter is set by looking up the reporter's
email address from a cookie, looking up the login name in a database to get a
UID and assigning this UID to the bug. Normally a null email in the cookie
would cause a problem but we happened to have a corrputed user in the db
with a null email address so the reporter was getting set as normal
(dmose changed this corrupted user to bogus-user@mozilla.org)

Simon, you created that test bug with a current build, didn't you?

Feel free to use mozilla to create test bugs to help debug this
and to reopen bug 17519 if necessary. In the mean time bugzilla
needs better sanity checking although i'm not sure how to guard
against pulldowns getting changed since the input isn't getting
changed to something invalid. Filing a cookie bug may be in
order as well.
Priority: P3 → P1
Summary: mozilla causing bugzilla database corruption → [dogfood] mozilla causing bugzilla database corruption
Added dogfood annotation, since this is causing Mozilla.org suggestions to not
use the browser for bug submission (a most common internal task).
I also upped the priority to P1, as this seems potentially damaging to the bug
tracking database (a Bad Thing).  I would have used P0 if it had existed.

It is critical that this bug be resolved (or we realize that it is not a
problem) ASAP, as we want folks to  be using the product to get their work
done... and the related message about "Please don't submit bugs using Mozilla"
is stopping folks.

Thanks,

Jim
cc: some form-loving gecko people.
Assignee: terry → dmose
Taking this bug for now, since Terry is on vacation.  I cleaned the corruption
out of the bugzilla database last night, and Dawn and I came up with some
possible sanity checks for Bugzilla last night, as it should be more impervious
to bogus form input.
another db oddity is that it appears that 3 outof 5 bugs assigned to the
active X wrapper don't belong there. These may be leftover problems from
the original form problem. The active x wrapper is the first component
in the browser listing.
In response to endico's 11:31 comment:

This could not have caused bugs to incorrectly be marked fixed, since that would
require checking the third radio button.  It also couldn't cause a bug to be
filed initially (incorrectly) to the wrong component.

To respond to endico's 13:10 comment:

The bugs incorrectly assigned to ActiveX Wrapper are probably from bug 17519.
The "View Bug Activity" log should be useful.  I'll take a look.
I took a look at the bugs assigned to ActiveX control that shouldn't be.  I
think two of them show a bug in Bugzilla, a bunch show bug 17519, and the other
one could be a bug in anything (e.g., IE 1.0) or user error:

bug 11634 was changed to "ActiveX Wrapper" component when its *Product* was
changed from NSPR to Browser.  I highly suspect this as a bug in Bugzilla, since
there's clearly no way to change the Component to a valid one when changing
Product.  Bug 1897 seems to show the same bug.

bug 5161 was changed to ActiveX Wrapper at the same time a number of other
changes to the bug were made (including deletion of QAC).  This could be user
error.  In the absence of any other cases, I think it must be treated as such.
It also occurred well before bug 17519 started.

The following problems do seem to have been caused by bug 17519 (user causing
change in ()):
bug 18526 (gagan), bug 17531 (mcafee), bug 14103 (slamm), bug 16482 (mcafee),
bug 16557 (paulmac),
Priority: P3 → P1
Summary: mozilla causing bugzilla database corruption → [dogfood]mozilla causing bugzilla database corruption
Looks like midair collision catching failed and sfraser accidentally undid jar's
mark of [dogfood] and P1.  Re-marking as such.

BTW, let me say again that I have sucessfully (modulo bug 16813, which makes it
easy to spot the ones I filed using Mozilla - they have extra blank lines) filed
a number of bugs using Mozilla.  See, for example, bug 19608, bug 19601, and bug
16808.
I suspect sfraser filed bug 20015 while investigating bug 16813 / bug 19954
(it's a reasonable thing to do while investigating those bugs - I filed both of
them and know them well...), and did so by pasting in a submission URL from 4.x
rather than by filling out forms in Mozilla.  sfraser??

If that's the case, I don't see evidence of any known bugs in current versions
of Mozilla that cause Bugzilla corruption.  Seemingly, the only bugs would be in
Bugzilla (not prompting for correct Component on change of Product; accepting a
submission URL pasted when there was no cookie).

If sfraser confirms my theory, I think the warning against using Mozilla on
Bugzilla can be retracted.  However, people should be adviced to read email
diffs from Bugzilla to watch for further problems.
That is, assuming M11 doesn't exhibit bug 17519, and people are told not to use
anything earlier than M11 release...
dbaron is correct -- I entered 20015 while testing form line break stuff.
There was one aspect of filing 20015 that I didn't mention; this was the first
time I had attempted to file a bug with mozilla. After hitting the Commit button
for the new bug, I got the 'login information missing' page, and entered my
bugzilla username and password there, and submitted that.
I've written some of the sanity checking code; it notices problems with the
database at runtime and also refuses to allow empty strings for certain fields.
I need to write more sanity-checking code so that bugzilla is more resistent to
confused form data.  Hopefully I'll get that done tommorrow.
Excellent news about the additional sanity protecting code.  Again, as soon as
we can feel confident that mozilla can be used for submission of bugs, I'm very
anxious to have the "warning, don't use ..." notice removed.  We really want
folks to use it for dogfood.

Special thanks for the Thanksgiving holiday repair effort!!

Jim
Good work. Its clear that bugzilla is doing the wrong thing when its fed a
null login name. This explains why bug 20015 wound up with a corrupted
reporter.

Another problem also occured when this bug was closed. Its product, component
and version changed. Simon did you do this on purpose? Did bugzilla prompt you
to choose a new component because the product had changed?
http://mg128-191.ricochet.net/bugzilla/show_activity.cgi?id=20015

In bug 18034 I noticed that reflow problems seem to be worse when the link
is slow. I set up bugzilla on http://mg128-191.ricochet.net/bugzilla/
for further testing. This is a 28.8 link.
Status: NEW → ASSIGNED
I spent most of my day working on the sanity-checking code; unfortunately it's
going slower than I had hoped, a large part of this was just wrapping my head
around various bugzilla internals.  The sanity-checking code for bug-entry is
partly done.  More as it happens.
In response to endico:
>Simon did you do this on purpose?
No, I didn't make any manual changes to any of the elements in the bug; I just
closed it. Mozilla must have mucked with those fields
But your browser might have.

That is, since Product was blank, there might (depending on how Bugzilla handles
lack of a valid Product) have been no options in the product select selected, so
the first one (Architecture) might show up as selected in the browser.  Thus
when you commit the changes, it becomes Architecture.  I'm not sure what the
possible versions are for Architecture, but that could also explain the version
change.  However, I'm not sure what would cause Browser-General -> Editor??
Could it have something to do with how Bugzilla stores components?
Could someone give an example of a bug submission url like Simon
used to enter a bug without a product?

I was testing earlier with a build from last night. The platform and
OS displayed were both "all" even though looking at the source showed
that the selected ones were supposed to be "pc" and "linux". I can no
longer reproduce this thought. Maybe i was hallucinating.
Whiteboard: [PDT+]
Putting on PDT+ radar.
OK, I've added a bunch of sanity-checking to bugzilla, which, if we're lucky,
will catch future such lossage in action.  Dawn has a version of bugzilla
running my patches up on <http://mg-20425418-89.ricochet.net/bugzilla/>.  If
everyone reading this could poke around there (maybe enter a bug, and change it
some, or even play with the multiple-bug changing code), that would be very
helpful.  Assuming that we don't see any problems with it by mid-day tommorrow,
I'll put these bits up on bugzilla.mozilla.org.
(at which time we'll then re-open the bugzilla database for general use by
mozilla)
Assignee: dmose → terry
Status: ASSIGNED → NEW
OK, I've checked in a bunch of sanity-checking code, mostly related to bug entry
and single bug updating, and it's running on Bugzilla now.  There's still a
bunch of bulletproofing to be done, but this was the most critical stuff, I
think.  I'm gonna reassign to terry now, let him look over the patches I've
checked in, and decide what he wants to with the rest of the bulletproofing
work.

Unless we see more problems, the Bugzilla database is once again open for
posting bugs with Mozilla.
I don't care any more
I have reviewed dmose's changes and heartily approve.
so does this bug need to be closed?
Summary: [dogfood]mozilla causing bugzilla database corruption → bugzilla form checking not robust enough
Whiteboard: [PDT+]
The bug does need to stay open, as there are still a bunch of spots in the
Bugzilla code that need to have tighter sanity checking.  However, since we
haven't actually been able to directly pin any of this on the browser, I'm
changing the summary and removing it from the PDT/dogfood radar.
bugzilla took me to this bug today, 12/9 build on linux.
Not sure why, just adding a datapoint.
so I just found my way here using NOVA. I was posting to a bug i had just posted
to by using the 'back' button instead of following the link and I got this
message:
"knob was not defined; this may indicate either a problem with bugzilla or a bug
in your web browser. Please help us track this down by adding coments to bug
20092."
so here I am. Those are my comments. Remember I used Nova, not mozilla.
Another bug that historically almost certainly corrupted some fields in
Bugzilla circa M10 is bug 15841 "SELECT has the first option selected when it
should have none" - FIXED. This would likely be responsible for some of the
earlier "ActiveX Wrapper" components that should have been something else.
Many of these got fixed manually as bugs were investigated and assigned to
their proper components.

The case of a combobox SELECT (i.e., a SELECT with size="1")
is covered by bug 16157, "Strict Mode combos shouldn't default to option 1
selected", still ASSIGNED, scheduled M13 or later. Bugzilla's show_bug.cgi
generated pages seem to have no DTD, which would (I assume) make the default
behavior the same as in Communicator and IE: submit the first OPTION if none
are SELECTED at submission time. That could make the "Architecture" product
appear in the scenario described by dbaron@fas.harvard.edu in the 11/28/99
16:30 comment, using any major browser OR Mozilla, unless "Product" is
specifically assigned a " " OPTION in this case, as "Target Milestone" is
(last OPTION) (it doesn't seem to be, but this ought to be easy to fix).
Break this out as an RFE?

If there is any chance that any bug or browser misbehavior could ever
result in two OPTIONs being selected in the show_bug.cgi SELECTs - the one
intialized as SELECTED and any other (especially the first) it may make sense
to make this one of the sanity checks before doing anything with the form data,
unless this is already done: none of these SELECTS seem to be MULTIPLE.

Finally, I would suggest regression-testing release candidates specifically for
bug 17519 and bug 15841 before every milestone release to prevent further data
corruption in bug reports submitted with those releases - another kind of
sanity check. The procedure would be very simple: enter a test bug, view,
add a comment but make no other changes, commit that change, view and look
for any changed selections in form controls. No change, no problem. This
procedure would also catch any similar problem that is not a DUP of 15841 or
17519 (as 17519 was not a DUP of 15841).
Bug 15841 caused selections that should not have been selected only in
listboxes, not comboboxes.  Bug 16157 is a bug with spec compliance - Mozilla's
current behavior is compatibile with 4.x.  Since component is a combobox, I
think the only bug that could have caused Product/Component corruption is bug
17519, right?
I agree.  Bug 16157 will not cause any problems with Bugzilla, fixed or no.  It
only applies to documents that specify HTML 4.0 strict DTD, which bugzilla does
not.

The only two I saw causing problems were 15841 which is fixed, and the later
regression 17519 which is also fixed.  Combos and listboxes shouldn't be a
problem anymore unless there is another regression.  Thanks!
OK. WTF? Bugzilla threw up an error when I was trying to read some bugs. It said
to add some comments about the error to this bug. Bugzilla says, "product not
defined" or something like that. Never seen this using 4.X to browse. First time
I use Mozilla and I get this.
The product not defined error comes from the lack of a cache.  (Even if you have
memory cache enabled, it checks the site every time.)  What is happening is that
mozilla is trying to reload a page that came from a POST form without
resubmitting the data.  A bug should probably be filed as a request to act like
4.x (once cache is working).
using Netscape Communicator 4.7 PPC MacOS 9.0
said legal version was not set
dbaron, the "posting forms again when revisiting them" feature request is
already reported as bug 17685, thanks!
so I just got directed here when I did this:
- entered some comments
- reassigned a bug
- typed a bad name into the CC field
- got a message saying the cc name was bad
- hit back (nothing happened)
- hit back again, got to the PREVIOUS bug I was working on
- hit forward, got the message to go to bug 20092

using mozilla, 1/6/00 build
Perhaps, because of bug 17685, there should be a separate error message when no
fields at all are defined, that doesn't direct people to this bug...
Posting Bug
   One moment please...
                           This is Bugzilla: the Mozilla bug system. For more
information about what Bugzilla is and
                           what it can do, see mozilla.org's bug pages.
A legal version was not set; this may indicate either a problem with bugzilla or
a bug in your web browser. Please help us track
this down by adding coments to bug 20092.

Above message received when trying to report bug with summary:
Typos in bug_status.html:  "ship[s]" & "the[y]"

When reporting the bug, the only option for version was "other".
I am using Netscape Communicator 4.61 under RedHat Linux 6.1.

Btw, there is a typo in the message pasted above: "coments".
I've been getting the error message pointing to this bug a lot lately, and I
figured out the problem.  See bug 23979.  It's a bug triggered by an
internationalization pref value related to charset detection, I think, (I don't
know how mine got set), but I removed the line from my prefs.js, and the problem
is better.
FYI, I do not have an "intl.charset.detector" user_pref line in my
~/.netscape/liprefs.js file.
Severity: critical → normal
Status: NEW → ASSIGNED
Priority: P1 → P3
So, I am bumping the priority and severity way down on this bug, as I believe it
is no longer much of an active problem, but more of a bug indicating that
further sanity-checking code would be a good thing.  Please speak up if you
disagree.
I marked Bug 25176 as a duplicate of Bug 8405. 
Bug 8405 got notification about this but Bug 25176
did not change at all. My comments also did not
survive. It seems that the problem is that Bugzilla
had to first log me in after I clicked "submit" and this
somehow messed up the process.
I did not have cookies allowed. and the version of mozilla used was not entered
properly into my bug report
Well, I just tried to enter a new bug with Mozilla Linux Build 2000021309,
and kept getting a page redirecting me to this error. I don't know if this
is a mozilla bug or a bugzilla bug.

You misspelled the word "comment" on that error page, btw. :-)


I tried to enter a bug using Linux build 2000021317 and got a message saying I
hadn't entered a legal priority telling me to go here
I just got this error message when I tried to create a new bug:

A legal priority was not set; this may indicate either a problem with bugzilla
or a bug in your web browser. Please help us track this down by adding coments
to bug 20092.

I get "A legal priority was not set" every time I try to file a new bug.

I can't submit a bug report against bugzilla. I get

"A legal bug_status was not set; this may indicate either a problem with
bugzilla or a bug in your web browser."

I also can't change the state of my (mailnews) bugs (or any mailnews bug BTW),
because the corresponding options are missing.
I bet the second problem is due to the new "unconfirmed" state. 
Read about it in the link at the top of this bug. If you can't
edit your bugs because you don't  have the proper permission
let us know and we'll fix you up.
The state change problem disappeared, sumbit problem still persists (also for
mailnews, not for browser).
Dawn, yes, I read <http://bugzilla.mozilla.org/confirmhelp.html>, but this
documents states, I should always be able to edit my own bugs. I also have all
mentioned permissions.
Hi, could you do something about not being able to 
submit a bug to MailNews area. It's blocking my work. 
I have some bugs which need to be entered and I get blocked
by ""legal status" msg like others have reported. ASAP, pelase!
Raising severity to BLOCKER per momoi's request.
Severity: normal → blocker
I had the same problem. I can't submit new bugs to the webtools, documentation,
or mailnews products. I can however submit new browser bugs. This is the
same from both my windows and linux machines using 4.x 

A workaround is to submit your new bug as a browser bug and then change the
product and component. I was able to create a mailnews bug 28167 this way.
I found the problem with state changes, filed bug #28175 about it.

Dawn, good idea to change the component.
In the Browser New bug form, we have "Initial State" form
option. This is lacking in Mail New bug form, and possibly
others. Not having this option in the form is probably
causing this problem.
CC'ed myself -- until my concern is resolved.
OK, I have fixed the bug I introduced last night that prevented anyone from
entering any new non-Browser bugs.
I have received email indicating that people without permissions can't add
comments to this bug.  I have turned off all of my permissions and am trying it
out.
Oh, duh.  That attempt to reproduce didn't work because I own this bug, and
those people don't.  Anyway, I have fixed that problem, too.

Restoring severity back to normal.
Severity: blocker → normal
I did the following

1. go to last bug in list.
2. press stop in brower before the page loaded
3. press back

I received a 'knob not assigned' warning after submitting a bug change report.

On a related note, it would be nice if the fields I don't have the power to
change weren't changeable ... the URL, for example, if I'm not the original
poster (or sufficiently empowered).

tara@tequilarista.org is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)
Assignee: terry → tara
Status: ASSIGNED → NEW
Bugzilla asked me to comment on this bug.  I hit the back button to return to a

previous page in Bugzilla and got a Product Not Defined or similar message.



I tried changing the STATUS of bug 34552 with NetPositive (browser under BeOS R5 PE) and I got the following

Bug processed 


 


product was not defined; this may indicate either a problem with bugzilla or a bug in your web browser. Please 
help us track this down 
by adding coments to bug 20092.
I got the 'product was not defined' error after successfully submitting a bug
change, then clicking on a related bug from the resulting screen and then
hitting back.

oops - this was caused by my hitting the back button after viewing a bug i'd just modified.  
i'm using the beos' netpositive v2.2...
> oops - this was caused by my hitting the back button after viewing a bug i'd
> just modified.  

I think this is already known as bug 17685.  Clicking forward and back buttons 
won't repost form data, which is why you ended up on the error page.

> i'm using the beos' netpositive v2.2...

Cool!
http://www.bedepot.com/Products/Be/NetPositive.asp

Oops!  I somehow interpreted "NetPositive" as "Mozilla" in Justin's prior post.  
Oddly enough, you would see the same bug if you were using bugzilla with 
mozilla.  I guess it is just a divine coincidence that NetPositive has the same 
bug (not reposting form data with back and forward buttons)
the title says all..

I was using Netscape Communicator 7.2 to log a mozilla bug when it (bugzilla) 
asked me to comment on this bug.

Argggg.  Dawn, I'll ping you on this online.
Status: NEW → ASSIGNED
Priority: P3 → P2
what is Netscape Communicator 7.2  :-)  Netscape...year 2010.
I'm using Warpzilla, Mozilla for OS/2, while updating some bug, and i was
told due to a bug in mozilla/bugzilla to report here.
(using custom pre-M17 build for OS/2)

build 2000021408, win95.

Tried to add a comment to bug 45707, wrote the comment, let it sit on my PC for
almost an hour, then when I said "commit" I got the "didn't happen" message that
said add a report to this bug.
I filled in http://bugzilla.mozilla.org/enter_bug.cgi?product=Browser, and
http://bugzilla.mozilla.org/post_bug.cgi said 'A legal version was not set;
this may indicate either a problem with bugzilla or a bug in your web? browser.'
The "version" field was "other"; the form offered no other option.
The values were as in Bug 46260, except I had Assigned to: sfraser instead of
Cc: sfraser@netscape.com, and Summary/Description were a bit different.

Possible related causes:
(1) I ran netscape 4.73 with javascript off.
(2) I had tried to set 'Assigned to' a few times but failed with illegal
username, and "succeeded" (to the point of reaching the new problem) when I
tried username 'sfraser'.
Bugzilla gave me the same message that brought others here, asking me to "help
us track this down by adding comments" to this bug.  All I had done was to use
the Go menu to return to "Bug processed" page in the history (wanting to find
any Bugzilla page with a convenient footer).  It asked me whether I wanted to
repost form data, and of course I clicked Cancel rather than resubmit a bug
report comment.  I was running Mozilla build 2000072408 under MacOS 8.6.

In a probably unrelated incident, Mozilla crashed while I was typing this
comment the first time around.  I've reported that as Bug 46629.


I'll try reproducing it.  The act of submitting this comment should reproduce
the conditions that led me here.
Reproduced successfully. I returned to the 'Bug processed' page, I typed in 

another URL (www.nasa.gov), let the page load, used the Go menu to back up, and 

clicked Cancel in response to the question about reposting. It gave me the same 

message, asking me to add to this bug report.



I used the same Mozilla build to submit the report. (I composed it elsewhere 

because I didn't trust it not to crash! And ironically, just as I was editing 

those words... but that's Bug 46629.)


I sucessfully(I assume?) updated a bug on a bug list to --> VERIFIED state and
when I tried to click on 'Show List' in the resulting page nothing happened...

So i click reload and I'm asked if I want to repost the form data, I clicked
cancel and as you can see, here I am. I was told that I 'failed to select a
product' or some such
Win32 2000082313
I was entering a change to bug 50091, and hit commit, and it took me to a page 
that said the product was bad. I hit back, saw that the product was good, and 
commit again, and this time it worked. I then hit show list, and then back, and 
it asked if I wanted to repost form data. I clicked Cancel, and it took me to 
the bad product page again.

For added fun, I have two duplicate "Additional Comments" widgets up, both 
showing every keystroke (also all the widgets between "leave as assigned" and 
"Votes for bug 20092".

When I tried to add this comment via mozilla I failed again.  Now using NS 4.7x
The "repost form data" problem is being tracked in bug 46338 and bug 43123.
Updating QA Contact
QA Contact: asa
"knob was not defined" when trying to submit additional comment to bug 52137
(yes "trying", because the comment wasn't submitted).

My web browser was Opera 4.02.0.762 / Windoze 2000.

After commenting on another bug, I got a message stating that no valid product
was selected.  Win98  Moz Build 091212.

This is a strange bug since I'm using Moz at work and creating a web interface
using forms a good deal and haven't had any problems that caused any corruption.
 Will let you know if that changes.
build id: 2000091908
mozilla w32 9/26-8 using the back button and clicking cancel.
OS: Linux → All
Same here: I clicked the back button, hit "cancel" because I didn't want to
post the data with my bug changes again, and got that page asking me to add
a comment to this bug.

ooh, Net+2.2, going back.
Showing up under Mac OS 9.0.4, with Mozilla build 2000092804-M18.

Same here: I clicked the back button, hit "cancel" because I didn't want to
post the data with my bug changes again, and got that page asking me to add
a comment to this bug.

Not sure if this is the reposting form data bug or not.

    I don't know if this is the correct bug, but I managed to change
bug 36358 from assigned to new although I'm not allowed to do something
like this. This is how I did that:

    I wasn't logged in to Bugzilla when viewing that bug. Then I added my
comment, and logged in in another Mozilla window (see bug 20122 for the
reasons and my comments there for the workaround I'm using). Then I hit
commit.  Bugzilla complained that I tried to change the owner or something
from "leaf@netscape.com" to "leaf@netscape.com (Daniel" (without the
quotes).  So I hit the back button and deleted the " (Daniel" from the
"assign to" field. Unfortunately Mozilla forgot what I entered in the
textarea input field (another bug! Does anybody know the number?), so I
had to enter my whole comment once again. I hit commit again and this time
Bugzilla was happy with it.  Maybe Bugzilla doesn't handle the two pairs
of parens in leafs id correctly.

I think that this was a problem with my browser, my page in NS6 started getting
all wacky. I am not sure though. Bugzilla asked me to comment.
I think that this was a problem with my browser, my page in NS6 started getting
all wacky. I am not sure though. Bugzilla asked me to comment. knob wasn't defined.
My webbrowser is kfm from KDE 1.2, when I was asked to submit report.
2000121404 on Win98 when hit the message that told me to make a report here.
had just sent through a note on another bug.
I was just asked by processbug.cgi to add a comment to this bug. The error message
was "product was not defined", and what I did was add a comment to one bug, hit
commit, then I got an error response from the web proxy because of a timeout,
then I hit reload and got that response.
Right, exactly the same for me, adding a comment to one bug, 55028, and I got a
message about undefined product and a request to add a comment here.
Got the "knob was not defined" message entering comment on bug 67007 using
Mozilla trunk build 2001-01-19-04 on win2k.
Additional Info (sorry for the spam): The error occured while I was doing a pull
and my 28.8 connection was loaded heavily. 
See also bug 67482 "real names with parens ( ) confuse bugzilla"
Browser version detection failed for communicator 4.74-linux (as suppied with
SuSE 7.0). Only "other" was selectable.

The concept has a problem with my (un?) typical setup: I use the old version for
production (bevause of it's well known quirks and features) and the mozilla
trunk for testing only.

A legal component was not set; this may indicate either a problem with bugzilla
or a bug in your web browser. Please help us track this down by adding coments
to bug 20092.

I'm using Netscape Communicator 4.76 to fill out bug 68613.  It looks like the
proper component in the Component field wasn't carried over from the previous
form.

Just following orders...  :)
Got the "knob was not defined" message entering comment on bug 32087 using
Opera 5.0 on win98.
While trying to add myself
wtanaka@yahoo.com
 to the CC list for bug 72313 just now
Sat Mar 24 23:19:33 PST 2001

(and leave the rest of the fields the same)

I got a message saying product not defined (and it instructed me to add comments
to this bug)

I'm using mozilla for linux x86 build 2001031821

I tried again, and it worked fine.
I got this message:

Bug processed
product was not defined; this may indicate either a problem with bugzilla or a bug in your web browser.
Please help us track this down by adding coments to bug 20092.

I am using Opera 5.

Just following directions.
Target Milestone: --- → Future
I just got

Bug  Processed
knob was not defined; this may indicate either a problem with bugzilla or a bug in your web browser. Please help us track this down by adding coments to bug 20092. 


when trying to add my name to the CC of bug 73490 using Omniweb 4.0 CF3
I have updated the CC field of other bugs with the same browser. My name was not added to the CC field. I hit back to get to the bug and reloaded and added my name again and it worked.

If you want any more info, Add me to the CC field and ask.

I just got the same comment Marcus got, trying to add a comment to a bug.
i have unkowingly used mozilla to enter bugs (as netscape 4.76 kept crashing on
login).
now (linux build 2001050721) mozilla crashes on login, and ns 4.76 doesn't.
but upon submitting a new bug with ns i get an error msg that "a legal version
was not entered" (the field "version" only contained "other")

rgds markus
Got "product not defined" today through my own error... I hit the page
http://bugzilla.mozilla.org/process_bug.cgi directly.  Bugzilla should perhaps
show a better error message in this situation.

moving out of future because we need to quantify what "robust enough" is and make 
it happen.  There's been a lot of form validation stuff fixed in 2.14 recently, I 
don't know how much of it applies to this bug.
Target Milestone: Future → Bugzilla 2.16
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → 2.10
OMNI4.0.5
steps:
1. load bug 20092
1' observe (*) Leave as ASSIGNED
2. click http://bugzilla.mozilla.org/process_bug.cgi
3. go back
3' observe ( ) Leave as ASSIGNED
4. click commit
4' receive notification explaining that I should comment here
Sending bugreport to omniweb4@omnigroup.com
Tried to log with invalid username, not java and no cookies. Using Mozilla
2001080110. I saw my correct username next to the Logout at the bottom of this
page, but the Commit button said I had an invalid password.
I used Logout, tried to login again, had to request a new password. Hope the
Commit button works.
No, it didn't; it said the invalid address didn't exist, although I had entered
my valid address.

OK, it worked. I went to the Query form, requested bug 20092, entered my data
(which I had prodently saved in a local file on my machine, and hit Commit. Now,
on to the bug I was actually intending to submit :-)
Tried to add my e-mail as a CC:; got invalid password again. Trying query/commit
maneuver again.
No, I still see the invalid e-mail message again. Loggining out, querying this
bug-id, and trying Commit. Should work, crossing fingers.
Oops, forgot to add myself on the CC: list.
Trying now.

I now realize I was trying to enter an e-mail address not registered in mozilla.
What confused me was that the error message appears after the login; I suggest
validation that Bugzilla can do without logging in be done before the login.
1. The "Add CC:" field is special, because it seems to be the only text entry
field that needs validation; furthermore the validation database can be changed
by logging in on the fly! I suggest a note to that effect next to the "Add CC:"
button. A "Create Account" link would make it easier for posters to create their
account and log in before attempting to use "Add CC:".

2. In the current Bugzilla 2.15, the only indication of being logged-in is down
at the bottom of a potentially-log report. Not fun when dealing with slow phone
lines and/or interrupted transfers. I suggest the fact of being logged in or not
should appear next to the Commit button.


Bug No. 99075 showed "Bug processed - component was not defined; this may
indicate either a problem with bugzilla or a bug in your web browser. Please
help us track this down by adding coments to bug 20092" when adding a simple
comment to it. Tested with IE 5.5 Win NT
I attempted to correct a typo in the description of an attachment to bug 99435
that I had already uploaded. I was able to type in the changes, but when I hit
Commit, I was only told then that I didn't have the required update privilege. I
would have liked to know that before beginning to type my chage in.
I just hit this (product not defined) by going to http://bugzilla.mozilla.org/ -
somehow mozilla 0.9.4 was sending a GET for process_bug.cgi with no content?
This was repeatable, and may have had something to do with my net connection
dying after processing a bug, but before the result came through. (The bug I
modified did get processed)
Actually, ignore that - _every_ url I went to tried to send to
bugzilla.mozilla.org/process_bug.cgi. Then I crashed.
fun bug.
http://bugzilla.mozilla.org/show_bug.cgi?id=106797
i was writing a comment in response to

------- Additional Comments From Matthias Versen (Matti) 2001-10-25 17:34 -------

I was going to CC some people, change the Product to Tech Evangelism, and
reassign to default owner.

However before i could do this, jst changed product and component to
techevangelism/english:us.

so my reassign brought me here because all i was doing was Tech Evangelism:
<random browser component> which bugzilla decided was a change from Tech
Evangelism: <valid TE component> and hence was not a valid component.

-- I was of course relying on bugzilla to allow me to select a component later.

I should have gotten a collision warning.
Resetting owner and QA ...
Assignee: tara → justdave
Status: ASSIGNED → NEW
QA Contact: asa → matty
We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
using OmniWeb 4.05
    http://www.omnigroup.com/applications/omniweb/
on Mac OS X 10.1.1
adding comment to bug 105486 after having just succesfully added one comment and two attachments.

said knob was not set

hit my back button, then submitted the comment without error
Ok I just got the knob not defined error AND I have somewhat of an explanation...

I tried marking a bug a duplicate of another.  Someone beat me to it.  I hit
back,  Mozilla re-fetched the page from the server for whatever reason, and then
re-applied my field changes.  My text was back in the additional comments
textarea and it also (assumedly) re-set <input type=radio name=knob
value=duplicate selected>.  The only problem though is that the duplicate knob
didn't exist anymore, so it didn't select anything.  Not sure if this applies to
any of the other bugs either, but that's what it was in my case.
again with the 'knob was not defined'.
Still using OmniWeb 4.05 on MacOS X 10.1.1

I'd posted several comments w/o error between this
and the previous bug report.

This time, however, when I hit 'back' and tried to resubmit,
I again got the 'knob was not defined' message.

Let me try again... 'back'... 'Commit'... another error.

Hmmm... logging out and back in of mozilla...

'back', 'Commit, another error, 'back', 'Commit', error.

OK, try a new window

'Commit'... success!
posted comment to bug 105486 at 2001_11_29 05:54

now I wonder if I'll be able to post this comment,
or if I'll need to do that in a new window...

If you see no further text in this comment, then
I was able to submit it in this window..........
Seeing 'knob was not defined' with 2002031608/Win2K with bug 131577. I'm
submited some comment, but mid-air collision happens (os and cc fields). So I
returned via Back button and reloaded page. Values entered in comment, cc and
keyword input boxes disappeared, so I written them again. After commit message
'knob was not defined' appear. Hope, it could help you.
Addition for comment #130:
BTW I returned to bug page now and any of radios with name 'klob' wasn't setted.
Seeing 'knob was not defined' with 2002041503/Win2K with bug 137702. I've
submitted some comment, but mid-air collision happens (cc field). So I
returned via Back button and reloaded page. Values entered in comment and
keyword input boxes disappeared, so I written them again. After commit message
'knob was not defined' appear.
Sure seems like a default value was set by bugzilla.   Did not appear checked
off in 2002041715 Linux
<input TYPE=radio NAME=knob VALUE=none CHECKED>
        Leave as <b>VERIFIED INVALID</b><br><input TYPE=radio NAME=knob
VALUE=reopen> Reopen bug<br>
<input TYPE=radio NAME=knob VALUE=close>
        Mark bug as <b>CLOSED</b><br>
Seeing 'knob was not defined'.  I have no clue what this mean.

it seems that some of the radio buttons was not defined...  but I do not know
which one...  after commiting this bug I will click on BACK button and I hope
that i will figure out what went wrong
 
We should close this bug out, and remove the comment from the source code if we
haven't already.

'knob not defined' is saying the radio button set where you choose your action
(leave as XXX, resolve ..., reassign ..., etc.) has not been set.  This is a
browser bug I think so we should give a nicer error message.


I just got the "knob" error with Mozilla 1.0.
no, this isn't a browser bug. It may be fixed with 2.16rc2, but theres some
interaction with midairs + reassignments, or something, which triggers this
every so often.
Er, I just tried adding the following plain old comment to bug :

  As I said in comment #0 it's in standards and in quirks mode. I'll attach a
  standards mode testcase. (4.01 strict is standards mode, isn't it?)

and it gave me:

  knob was not defined; this may indicate either a problem with bugzilla or a
  bug in your web browser. Please help us track this down by adding coments to
  bug 20092.

I'm using 1.0.0 final on Win98:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
I meant, of course, Bug 150373 .

Several attempts to add my comment have failed consistently.
And then it worked when I submitted a version with spaces in front of the two lines
of text:

  As I said in comment #0 it's in standards and in quirks mode. I'll attach a
  standards mode testcase. (4.01 strict is standards mode, isn't it?)
This just happened to me when submitting a change with *no* radio button
selected in the resolution section. Yes, it's a browser bug, but Bugzilla could
be nicer about it. I'm not sure this is the only issue.
This is meant to happen if there was no radio button selected...

How did you manage that?
Got the internal bug "knob not defined" by the following steps:

1. Did not log to Bugzilla at first, cookies disabled.
2. Selected a bookmark which was a query for specific keywords. 
Bugzilla returned a lot of bugs. I middle clicked on bug 154228 to open it in
new window. Decided to make some comments on it, but I was not logged in.
3. In another browser window, I selected another bookmark which was a bug list
which needs authentication because it contains security sensitive bugs. I
enabled cookies and I got logged in Bugzilla.
4. Reloaded bug 154228 by reload and I was logged in as guninski@guninski.com
5. Made some comments and clicked commit.
6. Got internal bugzilla error
Not sure of exact steps, but was reading through todays bugs, did a couple of
searches.

Noticed a dup in the database, marked it as such. While marking dup, cc'd
myself. Went back to tab with bug it was a dup of, hit reload, and added self to
cc field, hit enter. Got knob not defined error, which said to report here.

Hitting back in that tab shows that no radio button is selected. HTML source
shows that it should be selected:
    <br>
    <input type="radio" name="knob" value="none" checked="checked">
    Leave as <b>NEW&nbsp;</b>

Normal reload does not fix. Shift-reload does.

Mozilla 2002052305 Mac OS X.
i was submitting comments to a bug when i got the error message "Bugzilla has
suffered an internal error. please save this page and send it to endico@mozilla.org"
in red, the following text was displayed ---
"knob was not defined; this may indicate either a problem with bugzilla or a bug
in your web browser"

This might be useful :- 
before submitting my changes to the bug, i had noticed that none of the radio
buttons (leave as new, accept bugs , .......) were checked.
another thing....... i had come to the bug page via a link provided in my email


Looked at a resolved-invalid bug (#165680).

While I was looking, someone reopened it.  I refreshed, then added a comment and
triggerred the knob not defined error.

Backed up, saved form to a file, then resubmitted and got same error.

John, this is the bug I mentioned to you after your form history tech talk while
you were in MV.  You say this is intended behavior for the browser.  I say it is
causing site developers (e.g. bugzilla) and users confusion.  Is there anything
that either Mozilla or the webtools developers can do here?
...  and the differrence between the HTML source I saved when I had this
problem, backed up, saved, and had this problem again and the HTML source when I
brought the bug up a few minutes later was....


351,356c351
<         <select name="cc" multiple="multiple" size="5">
<           <option value="jasonb@dante.com">jasonb@dante.com</option>
<         </select>
<         <br>
<         <input type="checkbox" name="removecc">Remove selected CCs
<         <br>
---
>         <input type="hidden" name="cc" value="">
724a720,750


Don't ask me why!

The problem is with certain cache settings, when going back we reload the page
from the network.  However, browsers try and be smart with form data and try to
recreate the last form state.  With Bugzilla's case though, the radio elements
change, so most implementations get confused and don't select anything.  There
is no knob value, and then when we submit, Bugzilla gets confused.

I haven't tested this at all, but this *should* fix the problem.  I'd like
jkeiser's opinion here before this goes further.  Also if someone could test
this, it would be appreciated.
If there is a way to get around it, I'd be happy to hear.  The problem is, the
radio button that was selected no longer exists, but we don't know that until we
have loaded the entire document (and in the case of DHTML, we don't even know
then) so we assume they are all false (since only the restored one can be true).
 We could potentially check each radio button with its default value until a
restore has occurred on the group, but I'm not sure the infrastructure required
to support that is worth it.

However, it does seem that Bugzilla's form checking *is* robust enough since it
checks for this condition :)
Comment on attachment 97349 [details] [diff] [review]
This should theoretically work around the problem

Yes, this is a decent workaround.  One thing you may be able to do better is,
if none of them are checked, find the first one where defaultChecked is true
and check that one.
Thanks jkeiser for the comments.  This adds the defaultChecked check you
mentioned, defaulting to selecting the first item in the list if none are
checked by default.
Attachment #97349 - Attachment is obsolete: true
Oops I had a logic flaw in my last patch.  I overwrote the value with the
default value if we found the default value before the userdefined value.  This
is the right patch.
Attachment #97351 - Attachment is obsolete: true
Talked with jkeiser and we may be able to do something here.  We'd basically
mimic the JS patch that I have in the forms c++ code.  This isn't guaranteed to
happen any time soon though, so I think it would be best to go with the JS hack
for now.  (Other browsers which fall prey to this may be saved as well). 
Alternately, if someone wants to make it so that if this happens, we display a
page with only knobs and give them an "Oops no item selected, but please pick an
option now" message or something, that would work too.
Depends on: 165836
Keywords: patch, review
In trying to report a critical bug that does not allow me to run Mozilla 1.01,
pressing the "commit" button of the report produced the following message:

  Bugzilla has suffered an internal error. Please save this page and send it
  to endico@mozilla.org with details of what you were doing at the time this
  message appeared. 

  URL: http://bugzilla.mozilla.org/post_bug.cgi

  bug_file_loc was not defined; this may indicate either a problem
  with bugzilla or a bug in your web browser. Please help us track this
  down by adding coments to bug 20092. 

My browser is a plain vanilla Navigator (only) 4.08; my system is Win98/SP2


I'm confused:

> With Bugzilla's case though, the radio elements change,

bz never changes the radio elements via dhtml. We change (in some cases) which
one is selected via js, but thats it.

Just so I understand this correctly, is this happening if I reload a bug via the
reload button, and in the mean time the bug has been closed, so fewer 'knob'
choices are available and the one I had selected if no longer availble, and so
the browser gives up, and doesn't select anything? I think thats pretty lame...

I also find it hard to believe that it explains all of this, since the default
radio is always available.
No, it is what happens when you try to go BACK.  (Very different from reload). 
On any form page, if you type some stuff in to a form, twiddle some radios,
checkboxes, etc. and click a link and then go back, it is expected that the form
state be the same.  All the inputs filled in as you had it, the checkboxes
checked, the radios checked, selects the way you had it, etc.  However,
depending on your cache setting, if you go back to a page, it refetches from the
server.  In that case, browsers refetch and then attempt to recreate the page as
you had it by filling in the correct form data.  When the form item is missing
though, nothing is filled.

Why would someone go back on a page?  Because the midair page tells people to go
back and fix their choices.  Perhaps a better fix would be to have the midair
page say "Oops, you midaired, these are the conflicts:" and outline them all in
the table.  Then BELOW that we should have the bug listed.  Users without JS can
copy and paste from the midair report.  Users WITH JS can click a button that
says 'Use my values.'  Or something.

Anyway, I agree with jkeiser, that our form checking is robust enough.  Bugzilla
should do one of the following:

1. Accept no value for any of its form submits and assume it to mean the default
value rather than barf with an error page.
2. Change the midair page as I described so users can avoid hitting back (though
that will not fully solve the problem as some users may hit back still).
3. Add JS to the page similar to what is in the patch so that going back
prefills in a default.

Or perhaps a combination of all 3 is best...
Well, the really big problem with using back and reload to re-fill-in your
values is that it will not resolve the midair conflict at all!  Instead it will
overwrite any values that were in the conflict with their pre-conflict values
(since that is what was saved in form state).  So encouraging users to use Back
at all is just a bad idea.
I have just seen a page with the text:
 Bugzilla has suffered an internal error. Please save this page and send it to
endico@mozilla.org with details of what you were doing at the time this message
appeared.

URL: file:///C:/temp/process_bug.cgi.html

URL: http://bugzilla.mozilla.org/process_bug.cgi
knob was not defined; this may indicate either a problem with bugzilla or a bug
in your web browser. Please help us track this down by adding coments to bug 20092.

here we go:

I added karnaze to cc 
pressed submit
mid aircollion
back
selected karnaze
ctrl x
reload
paste
submit
-> see the above message
I got the same error page described in the previous comment #161. here's a copy/paste of the e-mail i sent to the endico@mozilla.org address:


My first endevor trying to do something in bugzilla resulted in an error (" Bugzilla has suffered an internal error. Please save this page and send it to endico@mozilla.org with details of what you were doing at the time this message appeared. ")...

I tend to cause a lot of havoc whenever I use software, so I should have expected something like this. Anyway here's the approximate details of what I was doing at the time the message appeared...

I'm a new user of the chimera browser and was interested in doing some QA work on chimera. The follow list of actions leading up to the error page were all done using chemera version 0.5 (Build ID 2002090913)

(oh and yes i realize most of this probably doesn't have to do with the actuall error i got... but here's the whole story anyway...)

* i'm browsing around bugzilla, but i'm not logged in b/c i don't even have a login yet

* i want to mark a bug as WORKSFORME (#135804), so I choose the appropriate radio button and dropdown menu (and also enter a comment)

* i then hit "commit"

* it prompts me to log in, in order to complete the request

* since I don't have a login, i control-click a "~create new account" link at the bottom of the page and choose the "~open link in new tab" option from the menu

* i enter a valid e-mail address and my name, and it tells me to get my password from a mail it sent and then follow a link to log in.

* i check mail (in a separate browser window). get the password. follow the link to log in (back on that second tab of the first browser window). log in. change my default query. change my password.

* i then decide to change which e-mail address i use for my log in... so, i enter a new e-mail address, it sends mail to both accounts so i can confirm the change. i confirm it the change (in the separate browser window) and get a nice page that says "Your Bugzilla login has been changed."

* now i finally go back to the first tab in the first window, where it had prompted me to log in to make the WORKSFORME change/comment

* it's kinda fuzzy in my mind, since i wasn't expecting to write a bug report on it, but i think that from here i pressed the back button to go back to the bug #135804 page, then hit "commit" again

* anyway, this time it gives me an error page saying i don't have permissions to change that field of the bug

("okay then", i think, "i'll just add the comment, then.".)

* so, i hit the back button to go back to the bug #135804 page. i then copy my comment, hit reload, and paste it back into the add-comment field (plus add some new text to the comment).

* I no longer have the option to mark it as WORKSFORME, so i just hit the commit button, and....

BAM! error page. This is the attached page that I'm sending you.


well i doubt that's helpful, but it's an interesting story. the end.

thanks,
/~pegli 

P.S. after writing this, I openned a new window, went to bug 135804, entered my comment again, hit commit, and this time it was successful.
Alias: knob
jkeiser: This just happened to me. I was commenting on a bug, loaded another url
via the urlbar (to check it), clicked back, and no radio buttons were selected.
I didn't try submitting like that, so I guess its possible that it may have worked.

The bug had not been changed by anyone in the meantime.

This is looking more and more like a moz bug....
knob not defined, Mozilla 1.2b, regarding bug 180512.
I just got this message/page while trying to add some keywords/status and cc
myself to bug 182040 (I had attempted a change prior but had a conflict so I
went back and reloaded bug 182040 and made the changes again):

Bugzilla Version 2.17.1
Bug processed
 

Bugzilla has suffered an internal error. Please save this page and send it to
endico@mozilla.org with details of what you were doing at the time this message
appeared.

URL: http://bugzilla.mozilla.org/process_bug.cgi
knob was not defined; this may indicate either a problem with bugzilla or a bug
in your web browser. Please help us track this down by adding coments to bug 20092.

Variables:
  

Actions: New | Query | bug # | Reports | My Requests | My Votes   Edit prefs,
users | Log out brade@netscape.com
Preset Queries: My Bugs

Hmm, I just got this again. I had reloaded the page, and the radio button wasn't
selected. However, I'd logged in in the meantime, and so I had teh additonal
group checkboxes. IS the extra form element confusing the layout save code (wich
has index as one of the keys, IIRC)
Bugzilla has suffered an internal error. Please save this page and send it to
endico@mozilla.org with details of what you were doing at the time this message
appeared.

URL: http://bugzilla.mozilla.org/process_bug.cgi

Submitted a change with updated OS/platform/severity, no comment.
URL: http://bugzilla.mozilla.org/process_bug.cgi
knob was not defined; this may indicate either a problem with bugzilla or a bug
in your web browser. Please help us track this down by adding coments to bug 20092.

I had filled in a comment for bug 187345, clicked on "commit", had to login,
and then got the message "Midair collision"
Because I didn´t understand wether I would kill the other comment or not,
I decided not to commit, but to go back to bug 187345.
When I was there, the box was empty, so I used my back-button, only to get to
another empty box.
I filled in two lines of comment by hand, pasted two lines from the
property-display from two gifs on a website named in bug 187345.
I selected and copied properties Location and Size of File.

When I clicked Commit, the message with the plea to report here came up.

just happened again:
I started to comment a follow-up to comment 168, and wanted to attach the file i
couldn´t submit. It´s been the first time I attached something, so I don´t know
much about the proceedings over here. After sending the attachment, I went back
to this box and wanted to sent it: Mid-Air collision was detected, with the
comment created by my Attachment. So again I didn´t proceed to report, but went
back to fill in this box now.

What I wrote before the collision:
Follow-Up to comment #168
After writing comment #168, I used the bck button to go back to the comment I
wrote for bug 187345. When I pressed Commit, same happened again, recommendation
to come over here.
So I copied the text from comment to 187345, and pasted it into another box open
on bug 187345 in another tab. That one I could commit.
Then I looked at the sourcecode of the un-commitable box, saved it to disk,
wrote a comment for here, and sent the stored source as an attachment to here.
Bugzilla has suffered an internal error. Please save this page and send it to
endico@mozilla.org with details of what you were doing at the time this message
appeared.

URL: http://bugzilla.mozilla.org/process_bug.cgi
knob was not defined; this may indicate either a problem with bugzilla or a bug
in your web browser. Please help us track this down by adding coments to bug 20092.

---
This happened when I was trying to add a comment to bug 188150.
Internal error msg: "Internal Error - Bugzilla has suffered an internal error. 
Please save this page and send it to endico@mozilla.org with details of what you 
were doing at the time this message appeared"




while postig a bug with Opera 7 beta2 Windows

I was trying to add this comment to bug : 189755.
"This seems to be a dup of 189749 ?

Reporter can you confirm these bugs are dups ?"

I was no loged in. I loged in. I missed typed the bug number, mozilla told my
bug number did not exist. Then I pressed the back button twice to copy the bug
number, pressed the forward button twice, did the revealent paste and pressed
commit.

Mozilla is build id is 2002120208 on Win2k server SP3. I'm behind a
firewall/proxy (which should ba a Netscape product, but I'm not sure).
Attachment #97352 - Flags: review?
Attachment #97352 - Flags: review? → review?(caillon)
Comment on attachment 97352 [details] [diff] [review]
Take 3 -- don't overwrite the actual value

When this gets checked in, we should also remove the reference to this bug
number in the error message so a new bug gets filed instead of someone
reopening this one.
Comment on attachment 97352 [details] [diff] [review]
Take 3 -- don't overwrite the actual value

Dave, surely you don't want me to review my own patch?
Attachment #97352 - Flags: review?(caillon)
that's yours?  oops.  I really wish the attachment interface would tell us who
uploaded it. :)  It does record it in the database after all.
Dave: I agree, request.cgi as well as the bug attachment table. Also, a link to
the comment for the attachment would be great too.
I got the same message as comment 171, on a bug which I'm reporter.  What
happened (I think) is that none of leave unconfirmed, resolution or reasignment
were selected.  I think the lack of a selection was caused by bug 159617 in
Mozilla, not a problem with bugzilla.
Bugzilla told me to post a comment here. I was making changes to bug 184274 and
noticed that none of the leave/assign/resolve radio buttons were checked.
Committing the form produced the red box error.

I went back, clicked Leave as Reopened, and committed again. Worked.

Not sure how the page managed to display with none of the buttons checked.
Comment on attachment 97352 [details] [diff] [review]
Take 3 -- don't overwrite the actual value

OK, just tried this out on landfill, and it either doesn't work, or doesn't
work in my test case...

1) Log out.
2) view a bug
3) mark it as a duplicate of itself
4) hit Commit
5) get prompted to log in
6) logged in with an account that has no privs
7) got error "can't make bug a dupe of itself"
8) pressed Back twice.	The form still had all 5 buttons (loaded from cache
instead of reloading).
9) I hit reload (not shift+reload).
10) form reloaded, the only radio button left was "leave as ASSIGNED" which was
NOT checkmarked.
11) Hit commit, got the "knob not defined" error.

View Source on the bug form did show the javascript function and the OnLoad
handler were in the web page properly.
Attachment #97352 - Flags: review-
Since we know this error is caused by a bug in Mozilla, and not Bugzilla, and
our javascript attempts have been at most a workaround for it, we need to fix
the error message to say so, and point people at the Mozilla bug and not this
one.  This bug is getting old, and there's obviously not much we can do from
Bugzilla.
Severity: normal → blocker
Status: NEW → ASSIGNED
Whiteboard: [wanted for 2.17.4]
OK, turns out the error message in question was a custom error message on
mozilla.org.  That error message has been replaced with one pointing at bug
165836 instead of this one (the message now reads "'knob' was not defined. If
you are using Mozilla, this is probably bug 165836").

This bug is now resolved to my satisfaction.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Whiteboard: [wanted for 2.17.4]
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: