Closed
Bug 84003
Opened 23 years ago
Closed 23 years ago
Can't paste in URL bar without clicking in Browser content area
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
People
(Reporter: kinmoz, Assigned: asa)
Details
In my mozilla Win32 Debug build from 06/03/01, I see the following assertion thrown when pasting into the URL bar textfield: ###!!! ASSERTION: NOT IMPLEMENTED: '0', file y:\mozilla\content\base\src\nsDocumentViewer.cpp, line 4064 ###!!! Break: at file y:\mozilla\content\base\src\nsDocumentViewer.cpp, line 406 To reproduce: 1. Copy some URL or text from some application. Doesn't matter where you get the text as long as there's something on the clipboard. 2. Bring up a new browser window. Make sure you don't click in the browser content area after it comes up! 3. Click in the URL bar and try to paste what's on the clipboard. You should see the assertion mentioned above, and nothing gets pasted into the URL bar textfield. Note that this assertion does not happen if you've clicked in the Browser content area before you tried to paste. Here's the stack trace to the assertion. NTDLL! 77f762e8() nsDebug::Assertion(const char * 0x02098df8, const char * 0x02098df4, const char * 0x02098dc0, int 4064) line 290 + 13 bytes DocumentViewerImpl::Paste(DocumentViewerImpl * const 0x02d24294) line 4064 + 35 bytes nsDOMWindowController::DoCommandWithEditInterface(const nsCString & {...}) line 4514 + 23 bytes nsDOMWindowController::DoCommand(nsDOMWindowController * const 0x045f0a20, const nsAString & {...}) line 4464 + 12 bytes nsXBLPrototypeHandler::ExecuteHandler(nsXBLPrototypeHandler * const 0x04540db0, nsIDOMEventReceiver * 0x04543850, nsIDOMEvent * 0x045f1934) line 309 DoKey(nsIAtom * 0x02c77070, nsIXBLPrototypeHandler * 0x04540db0, nsIDOMEvent * 0x045f1934, nsIDOMEventReceiver * 0x04543850) line 92 nsXBLKeyHandler::KeyPress(nsXBLKeyHandler * const 0x04543800, nsIDOMEvent * 0x045f1934) line 107 + 40 bytes nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x041f82b0, nsIPresContext * 0x02d23270, nsEvent * 0x0012f820, nsIDOMEvent * * 0x0012f3c4, nsIDOMEventTarget * 0x03c833b0, unsigned int 7, nsEventStatus * 0x0012f78c) line 1548 + 41 bytes nsGenericElement::HandleDOMEvent(nsGenericElement * const 0x041fc500, nsIPresContext * 0x02d23270, nsEvent * 0x0012f820, nsIDOMEvent * * 0x0012f3c4, unsigned int 1, nsEventStatus * 0x0012f78c) line 1674 nsHTMLInputElement::HandleDOMEvent(nsHTMLInputElement * const 0x041fc500, nsIPresContext * 0x02d23270, nsEvent * 0x0012f820, nsIDOMEvent * * 0x00000000, unsigned int 1, nsEventStatus * 0x0012f78c) line 1078 + 29 bytes PresShell::HandleEventInternal(nsEvent * 0x0012f820, nsIView * 0x02d238f0, unsigned int 1, nsEventStatus * 0x0012f78c) line 5517 + 47 bytes PresShell::HandleEvent(PresShell * const 0x02cebcf4, nsIView * 0x02d238f0, nsGUIEvent * 0x0012f820, nsEventStatus * 0x0012f78c, int 1, int & 1) line 5444 + 25 bytes nsView::HandleEvent(nsView * const 0x02d238f0, nsGUIEvent * 0x0012f820, unsigned int 28, nsEventStatus * 0x0012f78c, int 1, int & 1) line 377 nsViewManager::DispatchEvent(nsViewManager * const 0x02d23a90, nsGUIEvent * 0x0012f820, nsEventStatus * 0x0012f78c) line 2051 HandleEvent(nsGUIEvent * 0x0012f820) line 68 nsWindow::DispatchEvent(nsWindow * const 0x02d237b4, nsGUIEvent * 0x0012f820, nsEventStatus & nsEventStatus_eIgnore) line 712 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f820) line 733 nsWindow::DispatchKeyEvent(unsigned int 131, unsigned short 118, unsigned int 0) line 2380 + 15 bytes nsWindow::OnChar(unsigned int 22, unsigned int 0, unsigned char 0) line 2504 nsWindow::ProcessMessage(unsigned int 258, unsigned int 22, long 3080193, long * 0x0012fc2c) line 3040 + 33 bytes nsWindow::WindowProc(HWND__ * 0x000d0508, unsigned int 258, unsigned int 22, long 3080193) line 979 + 27 bytes USER32! 77e7124c()
Comment 1•23 years ago
|
||
You'll get this assertion any time that you try to paste when the content area is focussed (since the content area can't accept a paste). The real bug here is that someone left the Paste menu item (and key) enabled when you had focus in the content; they should be disabled.
Comment 2•23 years ago
|
||
I think the real problem here is that, when a new browser window comes up, the url bar *looks like* it has focus (you an type there), but it really does not (its controller isn't being called, and arrow keys etc don't work).
Comment 3•23 years ago
|
||
*** This bug has been marked as a duplicate of 83919 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•