Closed Bug 400443 Opened 17 years ago Closed 17 years ago

ASSERT: Insertion point for an menupopup view during a drag must be -1! when dropping on bookmark menu in menubar

Categories

(Firefox :: Bookmarks & History, defect, P3)

x86
Windows XP
defect

Tracking

()

RESOLVED FIXED
Firefox 3 beta3

People

(Reporter: cbook, Assigned: mak)

References

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

Attached image Assert Error Message
Build: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a9pre) Gecko/2007101905 Minefield/3.0a9pre STR: (note this seems to happen not everytime) 1. Go to a website with a favicon like bugzilla.m.o 2. Drag the Favicon to the bookmark menu item 3. Nothing happens - menue does not open (thats bug 337761) 4. Move the Mouse a little and then release the mouse button 5. A ASSERT pops up. See Screenshot
Flags: blocking-firefox3?
Version: unspecified → Trunk
Flags: blocking-firefox3? → blocking-firefox3+
Target Milestone: --- → Firefox 3 M10
Target Milestone: Firefox 3 M10 → Firefox 3 Mx
Target Milestone: Firefox 3 Mx → Firefox 3 M11
Priority: -- → P2
Priority: P2 → P3
Nice to see your as quick as ever Tomcat. Exact message is below ASSERT: Insertion point for an menupopup view during a drag must be -1! Stack Trace: 0:BMDH_onDrop([object MouseEvent],[object Object],[xpconnect wrapped (nsISupports, nsIDragService, nsIDragSession)]) 1:([object MouseEvent],[object Object]) 2:ondragdrop([object MouseEvent]) Changing Title to exactly match the assertion (same as your screen shot) to make dupe finding easier.
Summary: Assert: Insertion point for an menupopup view during drag and drop must -1! → ASSERT: Insertion point for an menupopup view during a drag must be -1!
Regression window is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-05-03+07%3A00&maxdate=2006-05-03+13%3A00 Maybe caused by Bug 336162? But in this case it is weird that branch doesn't have this bug.
Blocks: 336162
Keywords: regression
The Steps to Reproduce that I used were: - Drag the favicon onto the bookmarks menu label - Open the menu and admire the new bookmark - Drag the same favicon for the second time onto the bookmarks menu label
should be because insertionpoint from menu.xml returns this._cachedInsertionPoint that still points to the latest dropped item... this._cachedInsertionPoint should be cleared ondrop the bug is also reproducable with these steps: - D&D a bookmark item in the bookmark menu - try to drag the favicon from the location bar to the bookmark menu
Attachment #295917 - Flags: review?(mano)
Comment on attachment 295917 [details] [diff] [review] clear cachedInsertionPoint on drop still reproducable when: - drag a bookmark on the bookmark menu but drop elsewhere - drag the favicon to location bar so clearing review, needs additional fix
Attachment #295917 - Flags: review?(mano)
different approach, if dragging to bookmark menu put the item at the end of the menu by default
Attachment #295917 - Attachment is obsolete: true
Attachment #295942 - Flags: review?(mano)
I don't get this at all, shouldn't the item be placed wherever it was dropped?
er, ignore me, i misread the drop method context
What about nulling out _cachedInsertionPoint in onpopupshowing/hiding.
i had tried that but it was not working, onpopupshowing/hiding were not called every time and we should also null out _selection, i could try again but it did not work always... however there is no need to check insertion point when dropping on bookmark menu, since the bookmark dropped there should always be put at the end...
Summary: ASSERT: Insertion point for an menupopup view during a drag must be -1! → ASSERT: Insertion point for an menupopup view during a drag must be -1! when dropping on bookmark menu in menubar
Comment on attachment 295942 [details] [diff] [review] put dropped item at the end of bookmark menu ok. r=mano.
Attachment #295942 - Flags: review?(mano) → review+
Assignee: nobody → mak77
Keywords: checkin-needed
mozilla/browser/base/content/browser-places.js 1.79
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Keywords: checkin-needed
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: