Closed Bug 87408 Opened 23 years ago Closed 16 years ago

Page info should display the form data posted to a page

Categories

(SeaMonkey :: Page Info, enhancement)

x86
Linux
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: joe, Assigned: db48x)

References

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.1+) Gecko/20010622 BuildID: 2001062212 There should be a way of displaying what information was posted to a page. This is important for people who are writing web robots, and is also useful for debuging. both lynx and netscape 4 has this functionality Reproducible: Always Steps to Reproduce: 1.Go to a page with post 2.Submit the page 3.Get a new page back 4. No idea what was submitted to get that page Actual Results: Under page info there should be a box saying what was posted to generate a page
Just paranoid thought flashing in my mind... Security issues (user passwords, credit card #, etc...) there??
Summary: Page info should display the information posted to a page → [RFE]Page info should display the information posted to a page
I'm not entirely sure I see where this information is presented in ns4.7x. Both ns4.7x and mozilla show the entire url, which is usually enough to show all the form fields submitted, though not always. The patch I've attached to bug 52730 goes further and shows all the forms on the current page, and what fields will be submitted, as well as their current values. It's not quite the same, but very similar.
->XPApps GUI Features
Assignee: asa → blake
Component: Browser-General → XP Apps: GUI Features
QA Contact: doronr → sairuh
Bug processed has the following structure: http://bugzilla.mozilla.org/process_bug.cgi Form 1: Action URL: http://bugzilla.mozilla.org/show_bug.cgi Encoding: application/x-www-form-urlencoded (default) Method: Get Image: http://www.mozilla.org/images/mozilla-banner.gif </nc4output> I don't see whatever the reporter thought nc4 did, but pageinfo is daniel's sandbox.
Assignee: blake → db48x
Severity: normal → enhancement
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 106971 has been marked as a duplicate of this bug. ***
Summary: [RFE]Page info should display the information posted to a page → [RFE]Page info should display the form data posted to a page
mass moving open bugs pertaining to page info to pmac@netscape.com as qa contact. to find all bugspam pertaining to this, set your search string to "BigBlueDestinyIsHere".
QA Contact: sairuh → pmac
Component: XP Apps: GUI Features → Page Info
Depends on: 81202
Note that a potential(?) security risk is taken here when displaying POST data on a page which has username/password data posted to it. This is the type of issue that we tried to avoid in bug 121792.... So, do we want to fix this?
Summary: [RFE]Page info should display the form data posted to a page → Page info should display the form data posted to a page
With username/password, the password field is usually set as such. Maybe password fields could have a little message, like "passwords unavailable". Anything that can be seen in cleartext before the form is submitted is not likely to be so sensitive that it shouldn't be accessed in the page generated by that form, IMO. Anyway, I think this feature would be quite useful.
bug 121792 covered a similar issue, as far as sensitivity of passwords. imo, it would be best to follow suit, if this feature goes in.
What about splitting off the GET parameter names and values into a table similar to how a form about to be submitted is summarized? One could always scroll through the entire query string in the URL bar or in the URL element, but it is a pain in the neck. Underneath the "meta" section perhaps another section could be created to show these name/value pairs. It would be extremely helpful for development.
Product: Browser → Seamonkey
QA Contact: pmac
This is extension fodder e.g. <http://xsidebar.mozdev.org/modified.html#urlparams> WONTFIX.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.