* TITLE/SUMMARY Adobe form doesn't work (unless cgi output saved to file) * STEPS TO REPRODUCE 0) Launch Apprunner 1) Go to the "Shifty Hues" puzzle on the Adobe web site. (URL of http:// cgi1.adobe.com/newsfeatures/puzzles/imagehunt/shiftyhues/puzzle.cgi#top) 2) Click in the puzzle form (a form using image input types, with 66 form elements. Not an image map.) * RESULT - What happened Nothing. However, if you save the page source (from within Communicator 4.5) and launch that URL, Gecko handles it properly. (at http://www.prometheus-music.com/ gecko/adobe1.html) - What was expected Click on form element to be registered. (It would be nice if we had working Page Source functionality. That way, I could have said whether the problem resulted from Adobe sending different output pursuant to a specific User Agent, which would probably render this bug moot.) * REGRESSION - Occurs On Mac OS Apprunner (4.5.99 optimized build) Win32 Apprunner (4.5.99 optimized build [NT 4, Service Pack 3]) Linux Apprunner (4.5.99 optimized build) - Doesn't Occur On Mac OS Communicator 4.5.1 (RTM) * CONFIGURATIONS TESTED - [Mac] Power Mac 8500/120 (233 Mhz 604e), 64 MB RAM (VM on; 1 MB of VM used), 1024x768 (Thousands of Colors), Mac OS 8.5.1 - [Win32] Vectra VL (233 Mhz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP3. - [Linux] Vectra VL (266 Mhz P2), 96 MB RAM.

[Note that after changing the STR #210 resource of "4.51" to "5.0" to partially fake a 5.0 user agent, this bug still doesn't occur with 4.51.]

[3996/4459?]

[ignore last comment. wrong bug.]

Kipp, this looks like another <IMG ISMAP USEMAP=..> problem. Should you be handling these? If not, please reassign to Eric Pollmann. And I'm not just reassigning this to you to get my bug count down by tomorrow.

The test page has a bunch of <INPUT type=image ...> form elements on it, that for some reason don't work. Note however, that they do end up messing up the viewers history. So maybe they are sort of working? Anyway, it has nothing to do with USEMAP or ISMAP as its not a map.

Redistributing to M8...

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

Didn't make M8

Nisheeth, this seems to be a problem in nsWebShell with either DoLoadURL() or EqualBaseURLs(). The page is being seen as having the same base URL (it does) even though the page is different (the post data differs). The end result is that the page is not being reloaded as it should, but instead, the named anchor is shown. Can you take a look? Thanks.

Accepting bug, updating summary and status whiteboard.

I have a fix for this in my tree. Will check it in once the tree opens.

The fix is checked in. We would scroll the document to the named anchor target when a named anchor was clicked even when form data needed to get submitted. Now, we go ahead and submit the form data.

Nothing at all happens when I click on the Adobe form using the 1999072311 build (Necko M9 build) under NT; the puzzle works as expected in 4.7. Reopening, clearing resolution.

This fix was put in for non-Necko builds. I've added the same code to the ifdef Necko section of the code in nsWebShell::DoLoadURL(), so Necko builds should also be happy now. Marking fixed.

Looks fixed to me on the August 15, 1999 builds (NT).