63107 - On mouseover of submit button, show URL in status bar

Status: NEW

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

Description

[Matthew T (active 1999-2002)]

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.

Comment 1

[David Hallowell]

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)".

Comment 2

[Brian Staples]

I agree with David. To shorten his reccommended text, Submit Form To: (URL)
would be a bit better. Just my two cents.

Comment 3

[Neil Cronin]

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.

Comment 4

[HJ]

Ok and this one: Submit To: (URL)

Forms can be send to e-mail also!

Comment 5

[Matthew T (active 1999-2002)]

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

Comment 6

[rods (gone)]

This seems to be more of a browser issue - reassigning

Comment 7

[Neil Cronin]

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.

Comment 8

[HJ]

And if it goes to a javascript function in the action field, what should it do then?

Comment 9

[Matthew T (active 1999-2002)]

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

Comment 10

[Marcia Knous [:marcia]]

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

Comment 11

[Paul Chen]

Marking nsbeta1- bugs as future to get off the radar

Comment 12

[Blake Ross]

Taking...

Comment 13

[Blake Ross]

No other browser does this. Being realistic...

Comment 14

[Jonas Jørgensen]

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

Comment 15

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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

Comment 16

[Tony Mechelynck [:tonymec]]

Masayuki - are you still willing to work on this? (two years have gone by since you comment #15)

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 18

[Tony Mechelynck [:tonymec]]

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

Comment 19

[Thomas Goldstein]

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

Comment 20

[Ed Lee :Mardak]

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

Comment 21

[Alex Faaborg [:faaborg] (Firefox UX)]

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.

Comment 22

[Alex Faaborg [:faaborg] (Firefox UX)]

(switching to whiteboard for polish-relative priorities)

Comment 23

[Jonathan Watt [:jwatt]]

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