Open Bug 63107 Opened 23 years ago Updated 8 months ago

On mouseover of submit button, show URL in status bar


(Core :: DOM: Navigation, enhancement, P3)






(Reporter: mpt, Unassigned)


(Depends on 1 open bug)


(4 keywords, Whiteboard: [polish-hard][polish-interactive][polish-p3] )

Build: 2000121514, Mac OS 9.0

To reproduce:
* Go to <>.
* Mouse over the `Query page' link, and note that the status bar displays the
  text `'.
* Now, mouse over the `Show' button.

What should happen:
* The status bar displays the text `'.

What actually happens:
* Nothing.
OS: Mac System 8.5 → All
Hardware: Macintosh → All
When you mouse over that particular submit button it shouldn't show
 because that's not the page the form submits to!

This is perhaps a useful RFE (showing where the form submits to when mousing
over the submit button), however I think the statusbar should not just show the
URL but also have some text like "Submit form data to: (URL)".
I agree with David. To shorten his reccommended text, Submit Form To: (URL)
would be a bit better. Just my two cents.
I think the "submit form to: (URL)"  is a must if this is also implemented for
input type="img", otherwise there would be no way to tell if the image is a link
or a form.  right now the only way to know that an image is a form submission
button is the lack of status text.
Ok and this one: Submit To: (URL)

Forms can be send to e-mail also!
Ok, correction to original report:

What should happen:
* The status bar displays the text `'.

Including the text `Send form:' (or whatever) before the URL would only make 
sense if ordinary links had `Link:' before the URL. I think that would be a bit 
redundant. You could still tell the difference between links and form submissions 
by the type of cursor used (except when navigating between links using the 
This seems to be more of a browser issue - reassigning
Assignee: rods → vishy
at least on linux, there is no difference between mousing over an (input
type="img") and a mousing over a regular image link (besides the status text).
for an example, take a look at  notice that the "advanced search"
link is actually a form submission, while "personalize these settings" is a
plain link.

I think we need a way to indicate this difference if we do show the action url
in the status bar.
And if it goes to a javascript function in the action field, what should it do then?
Component: HTML Form Controls → XP Apps: GUI Features
QA Contact: bsharma → sairuh
[If it's a browser issue, then really moving to XP Apps: GUI Features.]

The difference between an image link and an image submission button is shown by 
the cursor.

When showing submission buttons URLs in the status bar, there is no need to treat 
javascript: URLs any different from any other URL scheme.
QA Contact: sairuh → claudius
Netscape nav triage team: per Alec Flett's pre-triage recommendation, this 
bug is nsbeta1-.
Keywords: nsbeta1-
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future
Assignee: vishy → blakeross
Target Milestone: Future → mozilla1.0
Target Milestone: mozilla1.0 → Future
No other browser does this. Being realistic...
Closed: 22 years ago
Resolution: --- → WONTFIX
Reopening. This is a valid RFE which would be useful to have, so there is no
reason for it to be WONTFIX. If /you/ don't want to implement it, just reassign
this bug to
Keywords: helpwanted
Resolution: WONTFIX → ---
Product: Core → Mozilla Application Suite
I think that this bug is very important for security issue.
I'll work on this.
Assignee: firefox → adamlock
Component: XP Apps: GUI Features → Embedding: Docshell
Product: Mozilla Application Suite → Core
QA Contact: claudius → adamlock
Masayuki - are you still willing to work on this? (two years have gone by since you comment #15)
No, I cannot work on this now. When I work on this, I'll assign this bug to me. If you want to take this, please take this.
(In reply to comment #17)
> No, I cannot work on this now. When I work on this, I'll assign this bug to me.
> If you want to take this, please take this.

No thanks - I'm not a coder, I'm just checking some old still-open bugs to avoid having them fall into oblivion. I'll temporarily reassign it to default then, until you can take it.
Assignee: adamlock → nobody
QA Contact: adamlock → docshell
Whiteboard: parity-IE, parity-Opera
Flags: wanted1.9.2?
Keywords: polish
Whiteboard: parity-IE, parity-Opera → [polish-hard][polish-interactive] parity-IE, parity-Opera
Sorry for this off-topic question, but is there a similar bug filed for RSS feeds? Ie: hovering the 'Open "RSS feed name"' option shows no URL in status bar.
Having had a quick look, I couldn't find it in bugzilla... maybe it's worded differently. Just don't wanna take time filing yet another dupe...
How should this be approached? The existing code path that implements showing the focused/hovered links works by...

On any event, the node can PreHandleEvent, so for nsHTMLAnchorElements (as well as area elements), they can eventually TriggerLink after checking it's a mouse enter/exit or focus/blur. This can lead to OnOverLink or OnLeaveLink and that will tell the browser chrome to set status, and the browser keeps track of the "overLink" status.

So for implementing mouseover submit/image, we could replicate all that or we could just do it from Firefox with event listeners.

Additionally, we could differentiate between POST and GET requests without overly confusing the average user and provides more information to the advanced user.

For GET requests, we can generate the URI that would be loaded if the submit button was clicked. E.g., http://site/submit.cgi?field=value

For POST, we can do as suggested earlier: Submit to http://site/submit.cgi
P3 - Polish issue that is in a secondary interface, occasionally encountered, and is not easily identifiable.

It is pretty common for people to submit forms, but not incredibly common for them to know how a form is constructed, or if they do know, common for them to expect to see anything in the status bar when they hover on submit.
Priority: -- → P3
(switching to whiteboard for polish-relative priorities)
Whiteboard: [polish-hard][polish-interactive] parity-IE, parity-Opera → [polish-hard][polish-interactive][polish-p3] parity-IE, parity-Opera
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Whiteboard: [polish-hard][polish-interactive][polish-p3] parity-IE, parity-Opera → [polish-hard][polish-interactive][polish-p3]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.