Closed Bug 106354 Opened 23 years ago Closed 6 years ago

Context menu for <input type="file"> doesn't include cut/copy/paste

Categories

(SeaMonkey :: UI Design, defect)

x86
Windows 2000
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: jonasj, Assigned: jag+mozilla)

References

()

Details

(Keywords: testcase)

Attachments

(2 files)

The context menu that appears when you right-click an INPUT with type="file"
doesn't include cut and paste. It does include copy, but it is disabled. In
addition, Select All doesn't select all the text in the field, but all the text
on the page.
Attached file Testcase
Keywords: testcase
->XPApps
Assignee: rods → pchen
Component: HTML Form Controls → XP Apps
QA Contact: madhur → sairuh
dup?

*** This bug has been marked as a duplicate of 63823 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
I don't think this is a dup. 63823 is about submit buttons, this is about
textfields for file inputs, and it doesn't look like fixing 63823 will fix this
one, since Select All on links/buttons should select the whole page while Select
All on the text field for <input type="file"> should select the text in the
field itself.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
-> default assignee
Assignee: pchen → trudelle
Status: REOPENED → NEW
->html form controls
Component: XP Apps → HTML Form Controls
really
Assignee: trudelle → rods
QA Contact: sairuh → madhur
That's because at the moment we aern't doing anything special when over the file
control
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Clearing target from "Future" to blank to trigger more interest.
Because of this bug, I always have to Browse... to attach a patch/file to
bugzilla. Whereas if the bug was fixed, I could easily get the filename from my
editor and paste it straightaway in the field to that effect. Nav4x allows doing
that.

If Mozilla can just allow to paste (Ctrl-V) in the input field like Nav4x it
would be a start.

Cc:ing some folks from bug 140262 where the case of <input type=password> was
addressed.
Target Milestone: Future → ---
So... adding that option to the context menu is trivial (see bug 140262).  Does
it do the right thing once it's there?

Also, what would selecting "paste" after right-clicking on the button part of
the input do?
From what you said in bug 140262 comment 13:

"Input type=file is a little odd because we don't really have a way of
differentiating between the button and the textfield in it....  I'm not really
sure what we want to do there, and I'm loath to change our current behavior
without an explicit UI spec."

rods might know how to tell what is clicked, rods?
rods, did you see comment 11 above?

bz, any clues from XBL? When one clicks on the input field, the filepicker
doesn't show up. But one clicks on "Browse...", the filepicker shows up. So XBL
has a way to differentiate between the two, no?
I really don't know how the <input type="file"> works internally, but since the
context menu operates on a DOM node, we'd need to pass it an anonymous node or
something to get it to do the "right thing".
Priority: -- → P2
Target Milestone: --- → Future
Here is an 'almost' working patch. The problem it has is in the 'event' here:

+  onpopupshowing="gContextMenu = new nsContextMenu( this, event );

It currently passes the event mangled by XUL. If the usual DOM event that one
gets on the page could be passed there, the patch will work.
Whiteboard: data:text/html,<input><isindex><input oncontextmenu="dump('Hi!\n')" type="file">
Whiteboard: data:text/html,<input><isindex><input oncontextmenu="dump('Hi!\n')" type="file">
FYI - here is the debugging patch that I was using. I added some printfs in the 
function XULPopupListenerImpl::PreLaunchPopup(nsIDOMEvent* aMouseEvent) which
is called before the XUL takes over.

The originalTarget that is printed in the patch using |aMouseEvent| is the right 
anonymous node. That's why I said that if the DOM event of the page was passed 
in nsContextMenu, then the fix will work fine.

Index: src/nsXULPopupListener.cpp
===================================================================
RCS file: /cvsroot/mozilla/content/xul/content/src/nsXULPopupListener.cpp,v
retrieving revision 1.101
diff -u -r1.101 nsXULPopupListener.cpp
--- src/nsXULPopupListener.cpp  9 May 2002 01:43:18 -0000       1.101
+++ src/nsXULPopupListener.cpp  17 Jul 2002 21:03:17 -0000
@@ -194,6 +194,7 @@
 nsresult
 XULPopupListenerImpl::ContextMenu(nsIDOMEvent* aMouseEvent)
 {
+NS_ASSERTION(0, "XXXrbs - ContextMenu");
   if(popupType == eXULPopupType_context)
     return PreLaunchPopup(aMouseEvent);
   else
@@ -231,6 +232,21 @@
   mouseEvent->GetTarget( getter_AddRefs( target ) );
   nsCOMPtr<nsIDOMNode> targetNode;
   if (target) targetNode = do_QueryInterface(target);
+
+{
+  mouseEvent->GetTarget( getter_AddRefs( target ) );
+  nsCOMPtr<nsIContent> content(do_QueryInterface(target));
+  printf("Target -----------------\n");
+  content->List(stdout);
+}
+{
+  nsCOMPtr<nsIDOMNSEvent> event(do_QueryInterface(aMouseEvent));

+  event->GetOriginalTarget( getter_AddRefs( target ) );
+  nsCOMPtr<nsIContent> content(do_QueryInterface(target));
+  printf("Original Target -----------------\n");
+  content->List(stdout);
+}
+

   // This is a gross hack to deal with a recursive popup situation happening in
 AIM code.
   // See http://bugzilla.mozilla.org/show_bug.cgi?id=96920.
After digging a bit in this bug, I came to the conclusion that it can't be fixed
with the ingredients of XUL 1.0. The content model for <input type="file"> is
like this:

+ <input type="file">
|- anonymous child: <input type="file">     -- for the input fied
|- anonymous child: <input type="button">   -- for the Browse... button

For any click, document.popupNode is set to the non-anonymous file node, and I
couldn't find a way for scripts to recover the real anonymous node that was clicked.

To fix this requires either:
a new document.originalPopupNode (rather than only document.popupNode that XUL
provides). This way, the real node that was clicked could be stashed there to
allow scripts to sort things out.

Or
The XUL's event.relatedTarget could be setup so that it stores that real node.
http://www.mozilla.org/docs/dom/domref/dom_event_ref20.html
This seems OK per the DOM spec -- that the relatedTarget is a "related" node of
some kind. In the case of onmouseover/onmouseout, the spec defines what it is,
but other cases remain to be defined. A XUL's usage of stashing the real
document node in the XUL's event.relatedTarget wouldn't be far off.
Blocks: 172047
So this is not a form controls issue in any way -- the layout code is doing the
right things (dispatching an event with the right target and originalTarget).

Back to where this should have been all along.
Assignee: rods → jag
Status: ASSIGNED → NEW
Component: Layout: Form Controls → XP Apps
Priority: P2 → --
QA Contact: madhur → pawyskoczka
Target Milestone: Future → ---
>So this is not a form controls issue in any way -- the layout code is doing the
>right things (dispatching an event with the right target and originalTarget).

There is a nuance worthy of stressing for someone wishing to take a stab at this
bug. Layout builds the internal data event, but by the time the event is
dispatched to the outside world, it is a copy (i.e., in the usual way, another
variable suitable for the outside world) of that data that is made by the XUL
back-end, and the data stashed in the copy is not quite identical. That's what I
tried to document in comment #15 and comment #16.
*** Bug 243205 has been marked as a duplicate of this bug. ***
*** Bug 243205 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
If the focused node is set and is the child of the popup node then it's probably
the anonymous input element...
Does this even make sense? The input does not contain a text field for a while now.
> Does this even make sense?

Just checked the test case and it doesn't look so any longer. Closing it. Please reopen if you think this still needs a fix.
Status: NEW → RESOLVED
Closed: 23 years ago6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: