Using today's NS verification build 51908 on Mac OS 8.6. Got to any bugzilla page, for instance the query URL above. enter some data, or use the default. click "Submit Query" Nothing happens. Enter a bug number in the footer. Hit return or click "Find" Nothing happens. Seems okay on Linux, Win98

reassigning

Anyone have a Mac with a recent debug build on it I can play with? Waqar, your old mac is missing the mac to pc monitor adapter so I can't use that one. :S

This seems like a serious regression, nominating for nsbeta2

Putting on [dogfood+] radar. We need this fixed for M16 release.

Amplification; clarification. I can submit forms fine using Mozilla build M16-2000052408. What's happening on my machi machine (imac DV, Mac OS 9.04, MRJ 2.2, carbon libs 1.0.4) is this. The display lags several characters behind my typing. Right now, I'm about seven characters on the display, as opposedto where my cursor's at. You don't see this at the beginning of a line, but rather it starts about seven characters into the line, and gets progressively worse as one proceeds across the line. When I hit a return, the "missing" text magically appears. When I submit the form here on Bugzilla, the text is magically there. I just don't see it as I'm typing. Just a bit annoying! Maybe this should be a second bug? I'm not sure, so I've posted here. FYI, I couldn't submit forms at all under Mac build 2000051908, but since this had been reported already, I didn't feel the need to amplify previous comments.

Methinks this is an invalid bug. I cannot reproduce this bug with today's build, MacOS 9.0. One question: - Can someone with MacOS 8.6 (e.g. bug reporter!) test today's build? However, there is one problem! I'm also unable to reproduce the bug with 2000051908 optimized builds from the download area in mozilla.org on MacOS 9.0. For what it's worth, I'm going to try updating my tree to a that timestamp, doing a debug build, and see if I can verify that this bug ever existed on MacOS 9.0. If it did, then I'm going to INVALID this. If not, and an 8.6 person still sees this bug, I'll need an 8.6 install to debug because I'm not seeing any problems with form submission on 9.0! Kurt: The text lagging behind you typing is a different bug, please search to see if it is already reported, and if not, open a new bug on it. This is also a serious usability issue!

This bug was filed against 8.6, so whether it works on 9.0 is not really a factor in whether a defect exists. You shouldn't mark this invalid, since that means that the described behavior is not a bug. In fact, some form submission does appear to be working again in today's 52508 build (bugzilla.mozilla.org bug #), but I still can't commit a bugzilla query form.

Removed the "CANT REPRODUCE (MacOS 9.0)" tag. I can reproduce it too on MacOS 8.6 and MacOS 9.0 with today's build. But but but... I can't reproduce it with a debug build from yesterday. That will be a lot of fun to debug!

Oy, silly me for pulling that time stamp build... Okay, I'll update to the tip tonight and work on this tomorrow!

Eric: I could reproduce the bug with the daily optimized builds only, not with my local debug build. I don't think that pulling the tip rather than a time stamp will make a difference. Instead, you may want to do an optimized build on your local machine and see if you can reproduce the problem.

Thanks Pierre, I'll give that a try.

I am *still* unable to reproduce this bug. Also tried the optimized daily build from yesterday: ftp://ftp.mozilla.org/pub/mozilla/nightly/2000-05-25-08-M16/mozilla-mac-M16.sea. bin Couldn't do an optimized build of my own because I'm mac illiterate and can't figure out how to start it! :S (mozilla/xpfe/bootstrap/macbuild/apprunner.mcp doesn't seem to know about my optimized build) Since I can't reproduce this bug, I don't have any way of fixing it. Can someone who is seeing this bug let me use their machine and/or describe *exactly* what they are seeing? Here's what I see: 1) Start up mozilla 2) Type this URL in the URL bar: http://bugzilla.mozilla.org/query.cgi 3) Type pollmann@netscape.com into the Assigned To Email field 4) Scroll down to the button labeled Submit Query 5) Move mouse over the button labeled Submit Query 2px outset border on the button is replaced by 2px solid black border 6) Press down the mouse button, but do not release it. 2px outset border replaced by 2px inset border. Dashed focus ring appears inside button. 7) Move the mouse pointer off of the button and release the mouse button 2px inset border returns to 2px outset border. Dashed focus ring remains. 8) Move mouse pointer over button, and depress mouse button again 2px outset -> 2px solid black -> 2px inset 9) Release the mouse button, while still inside the Submit Query button. There is a long pause here. The Security warning dialog appears to indicate that the information we are about to submit may be observed by others. 10) Move the mouse pointer off of the Submit Query button to the dialog box Submit query: 2px inset + dashed focus ring -> 2px outset, no focus ring. 11) Click on the Ok button on the security dialog The dialog is dismissed. Dashed focus ring reappears on the Submit query button Page clears, and is replaced by "Please Stand by..." Page clears again, Bug list appears. There's probably lots of exceess detail in here, but from the descriptions above I can't even tell if the problem is: 1) button won't respond to mouse events 2) button responds, but dialog box never appears 3) button and dialog box work normally, but form is not submitted 4) button and dialog work, form submitted, but new page doesn't appear Based on past form submit bugs: If 1), this is probably an events bug. If 2), this sounds very similar to bug 40213, and may be either a javascript or networking bug. If 3), this is probably a networking bug of some kind, but could also be a problem with the network security dialog. If 4), this is probably a bug with the page returned by the server and may be completely unrelated to furm submission. CC'ing some people who may have related bugs...

Updating status whiteboard as requested. I can't give an ETA until I can reproduce the problem, sorry!

this seems to work for me, debug build from 5/30/00... though i am asked multiple times if i want to submit insecure forms. i'd file a new bug for that but it's not all the time.

this seems to work for me, debug build from 5/30/00... though i am asked multiple times if i want to submit insecure forms. i'd file a new bug for that but it's not all the time.

Multiple dialogs bug is bug 41037, thanks Mike!

Still open on 2000-05-30-11 Commercial MacOS9. Will check on MacOS86 next.

Okay, tested on MacOS86 & MacOS9 on 2000-05-30-20-M16 Commercial build and: - MacOS86 works fine - MacOS9 bug still exists Updating OS to Mac System 9.0. Eric, Mike if you need to see this, feel free to stop by my cube.

updated status whiteboard

hrm, i use OS9 and have no problems submitting forms. I wonder if it's a commercial vs. mozilla thing or debug vs. optimized thing. I'm stumped. adding self to cc list.

MacOS9 2000-05-30-20-M16 Commercial from ftp://sweetlou works for me. Very strange, I'll stop by your cube, thanks Chris!

I can now reproduce the bug, thanks to some help from Chris! When the insecure form warning dialog box pops up, you must uncheck the "Show me this warning next time" box, then click okay. From that point onwards, form submission will be broken. So far I've only been able to reproduce this on MacOS 9, Optimized commercial build (Tested MacOS9 Optimized, Win Optimized commercial and Debug mozilla builds)

could it be related to the bug i filed yeterday where you crash unchecking that box and hitting return? seems like that dialog is the cause of lots of troubles ;)

Still fails for me (Bugzilla query form), this time using 53108 mozilla verification build on Mac OS 8.6

Restoring stomped summary and status. Peter, if you create a new profile, are you able to submit forms? Form submission worked for ckritzer and me, until we unchecked the "show this warning in the future" box in the insecure form submit warning dialog. I'll update status with an eta when I finish my debug build and do some assesment (assuming I can reproduce the bug there!)

I have a optimized Mac build that shows this problem. I've traced through. The psm-glue is returning an error code to the form, which aborts form submission. The error code comes back shortly after the "don't display warning dialog" pref is checked. Think I've got a handle on this now...

All that hoopla for an uninitialized variable... Fix in hand, and it's a one-liner. :)

Fix checked in. To verify: Get a Mac optimized build with the fix. (tomorrow's daily build should work) Create a new profile and use that profile. Go to bugzilla's main page. Enter any bug number and click Show. You should see a dialog box warning you of insecure form submission. Uncheck the "show me this warning again" checkbox and click Ok. This will submit the query. Click the back button on the browser twice. You will be back at the bugzilla main page. Click the Show button again. This time you should not see a dialog box, bug your query should still be submitted.

this is a test with no alert

Excellent work Eric. Marking VERIFED FIXED on: - MacOS9 2000-06-01-20-M16 Commercial Build - Linux6 2000-06-01-20-M16 Commercial Build - Win98 2000-06-01-21-M16 Commercial Build