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)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: jonasj, Assigned: jag+mozilla)
References
()
Details
(Keywords: testcase)
Attachments
(2 files)
347 bytes,
text/html
|
Details | |
3.45 KB,
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•23 years ago
|
||
Comment 2•23 years ago
|
||
->XPApps
Assignee: rods → pchen
Component: HTML Form Controls → XP Apps
QA Contact: madhur → sairuh
Comment 3•23 years ago
|
||
dup? *** This bug has been marked as a duplicate of 63823 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 4•23 years ago
|
||
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 → ---
Comment 8•22 years ago
|
||
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 → ---
Comment 10•22 years ago
|
||
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?
Comment 11•22 years ago
|
||
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?
Comment 12•22 years ago
|
||
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?
Comment 13•22 years ago
|
||
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".
Updated•22 years ago
|
Priority: -- → P2
Target Milestone: --- → Future
Comment 14•22 years ago
|
||
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">
Comment 15•22 years ago
|
||
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.
Comment 16•22 years ago
|
||
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.
Comment 17•20 years ago
|
||
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 → ---
Comment 18•20 years ago
|
||
>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.
Comment 19•20 years ago
|
||
*** Bug 243205 has been marked as a duplicate of this bug. ***
Comment 20•20 years ago
|
||
*** Bug 243205 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 21•19 years ago
|
||
If the focused node is set and is the child of the popup node then it's probably the anonymous input element...
Comment 22•7 years ago
|
||
Does this even make sense? The input does not contain a text field for a while now.
Comment 23•6 years ago
|
||
> 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 ago → 6 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•