Dragging bookmarklet from content area to desktop doesn't create webloc

VERIFIED DUPLICATE of bug 393609

Status

()

Core
Widget: Cocoa
VERIFIED DUPLICATE of bug 393609
11 years ago
10 years ago

People

(Reporter: Samuel Sidler (old account; do not CC), Assigned: Stan Shebs)

Tracking

({regression})

Trunk
PowerPC
Mac OS X
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

STR:
  1. Go to https://www.squarefree.com/bookmarklets/webdevel.html
  2. Drag the "shell" link/bookmarklet from the content area to the bookmark bar

Actual Results:
No bookmark gets created.

Expected Results:
Bookmark bar should get created.

This works fine on the branch and is, thus, a regression. Not sure if it's our fault or something in core that changed, but filing in Camino for now.

Note: This works fine for normal links, just not bookmarklets and also works as expected in Minefield, though their interface is obviously a bit different.

Comment 1

11 years ago
On branch, that drag advertised NSURLPboardType.  On trunk, it advertises MozillaWildcard instead.  When the item being dragged is in fact a URL, NSURLPboardType (or something else standard and similar) is what we want to advertise.  Not doing so will break many 3rd party apps.

Note that this still works for "normal" URLs.

Moving to Core, and re-summarizing to a breaking behavior that's shown by both Camino and Minefield.
Assignee: nobody → joshmoz
Component: Drag & Drop → Widget: Cocoa
Product: Camino → Core
QA Contact: drag.drop → cocoa
Summary: Dragging bookmarklet from content area to bookmark bar no longer works → Dragging bookmarklet from content area from content area to desktop doesn't create webloc
Target Milestone: Camino2.0 → ---

Updated

11 years ago
Summary: Dragging bookmarklet from content area from content area to desktop doesn't create webloc → Dragging bookmarklet from content area to desktop doesn't create webloc
Stan is working on fixing the other drag type regressions (bug 386790, bug 393609, bug 380582), I think.  Hopefully fixing the story there will solve this.

I can't imagine this not being a regression from bug 332913, but I haven't checked.
Flags: blocking1.9?
(Assignee)

Comment 3

11 years ago
My patched Camino build adds the bookmarklets, but the titles say "javascript(" etc, and clicking on them crashes.
(Assignee)

Comment 4

11 years ago
However, dragging to the desktop (aka the actual bug here :-) ) still doesn't work. It is a related problem to what I'm still working on, where the Finder is being picky about which urls it will accept.

Updated

11 years ago
Assignee: joshmoz → stanshebs
(Assignee)

Comment 5

11 years ago
OK, Camino with latest patch for 386790 works, and bookmarklets run correctly, but titles are still wrong. Oh, and ignore my previous "desktop" comment, the bug is misleadingly titled - drags to the *Finder* desktop don't work for anybody, including Safari, presumably because the Finder wants "http:" things, not "javascript:" things.
(Assignee)

Comment 6

11 years ago
My patch for 393609 apparently fixes this one too.

Updated

11 years ago
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Flags: blocking1.9?
Resolution: --- → DUPLICATE
Duplicate of bug: 393609
(Assignee)

Updated

11 years ago
Status: RESOLVED → VERIFIED
(Assignee)

Updated

11 years ago
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
(Assignee)

Updated

11 years ago
Status: REOPENED → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 363609

Comment 9

11 years ago
Erm, is there a reason this was reopened to be duped to the wrong bug? :-p

Duplicate of bug: 393609
(Reporter)

Updated

10 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.