4559 - [Webshell] Adobe form doesn't work (unless cgi output saved to file)

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Eli Goldberg]

* 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.

Comment 1

[Eli Goldberg]

[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.]

Comment 2

[Eli Goldberg]

[3996/4459?]

Comment 3

[Eli Goldberg]

[ignore last comment. wrong bug.]

Comment 4

[karnaze (gone)]

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.

Comment 5

[kipp]

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.

Comment 6

[Eric Pollmann]

Redistributing to M8...

Comment 7

[leger]

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

Comment 8

[Eric Pollmann]

Didn't make M8

Comment 9

[Eric Pollmann]

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.

Comment 10

[Nisheeth Ranjan]

Accepting bug, updating summary and status whiteboard.

Comment 11

[Nisheeth Ranjan]

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

Comment 12

[Nisheeth Ranjan]

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.

Comment 13

[cpratt]

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.

Comment 14

[Nisheeth Ranjan]

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.

Comment 15

[cpratt]

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