Build: 2000121514, Mac OS 9.0 To reproduce: * Go to <http://bugzilla.mozilla.org/>. * Mouse over the `Query page' link, and note that the status bar displays the text `http://bugzilla.mozilla.org/query.cgi'. * Now, mouse over the `Show' button. What should happen: * The status bar displays the text `http://bugzilla.mozilla.org/query.cgi'. What actually happens: * Nothing.

When you mouse over that particular submit button it shouldn't show http://bugzilla.mozilla.org/query.cgi 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 `http://bugzilla.mozilla.org/show_bug.cgi'. 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 keyboard).

This seems to be more of a browser issue - reassigning

matthew, 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 hotbot.com. 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?

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

Netscape nav triage team: per Alec Flett's pre-triage recommendation, this bug is nsbeta1-.

Marking nsbeta1- bugs as future to get off the radar

Taking...

No other browser does this. Being realistic...

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 nobody@mozilla.org.

I think that this bug is very important for security issue. I'll work on this.

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.

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.

(switching to whiteboard for polish-relative priorities)

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)