Closed
Bug 4559
Opened 26 years ago
Closed 26 years ago
[Webshell] Adobe form doesn't work (unless cgi output saved to file)
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
M9
People
(Reporter: elig, Assigned: nisheeth_mozilla)
References
()
Details
* 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.
Reporter | ||
Comment 1•26 years ago
|
||
[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.]
Reporter | ||
Comment 2•26 years ago
|
||
[3996/4459?]
Reporter | ||
Comment 3•26 years ago
|
||
[ignore last comment. wrong bug.]
Updated•26 years ago
|
Assignee: karnaze → kipp
Comment 4•26 years ago
|
||
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.
Updated•26 years ago
|
Status: NEW → ASSIGNED
Comment 6•26 years ago
|
||
Redistributing to M8...
Comment 8•26 years ago
|
||
Didn't make M8
Updated•26 years ago
|
Assignee: pollmann → nisheeth
Status: ASSIGNED → NEW
Comment 9•26 years ago
|
||
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.
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Summary: Adobe form doesn't work (unless cgi output saved to file) → [Webshell] Adobe form doesn't work (unless cgi output saved to file)
Whiteboard: Fix needed in the "decide to scroll rather than reload" logic inside DoLoadURL()
Assignee | ||
Comment 10•26 years ago
|
||
Accepting bug, updating summary and status whiteboard.
Assignee | ||
Comment 11•26 years ago
|
||
I have a fix for this in my tree. Will check it in once the tree opens.
Assignee | ||
Updated•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 12•26 years ago
|
||
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•26 years ago
|
||
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.
Assignee | ||
Updated•26 years ago
|
Status: REOPENED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Whiteboard: Fix needed in the "decide to scroll rather than reload" logic inside DoLoadURL()
Assignee | ||
Comment 14•26 years ago
|
||
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•26 years ago
|
||
Looks fixed to me on the August 15, 1999 builds (NT).
Updated•6 years ago
|
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•