Since bug 332913 landed, dragging a .webloc file into an opened tab/window does not open the URl (access the page). The location bar shows a file:///Users/phiw/Desktop/xxx.webloc. The same appears on window title or tab title. On 10.4: At first try, blank contents area If tried a second time, the content area shows an unstyled xml file. 10.3.9: shows the unstyled xml file immediately. This happens only in Camino atm. It works fine in Minefield 20061026. Opening by double clicking, or dragging to application icon on the Dock works correctly.
Is it camino-specific or does it happen in Minefield too? If it does, it should be reassigned to Core > Widget: Cocoa.
Well, regardless of where the bug is, it looks like no bug on weblocs got filed as a follow-up, so this can be that bug, and if it needs to move to Widget, fine. (I actually don't see an unstyled xml file on 10.3.9, just a blank page, but AFAIK I don't have any of the newfangled plist weblocs from 10.4).
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #2) > Well, regardless of where the bug is, it looks like no bug on weblocs got filed > as a follow-up, so this can be that bug, and if it needs to move to Widget, > fine. As I stated in comment #0, I can't reproduce this in Minefield (20061026 build, PPC). > (I actually don't see an unstyled xml file on 10.3.9, just a blank page, but > AFAIK I don't have any of the newfangled plist weblocs from 10.4). Hmm, I get a blank page now with a .webloc created on 10.3.9. Maybe I did only try with a 10.4 .webloc before. Regardless, the url doesn't load.
Target Milestone: --- → Camino2.0
The question is not whether this is Camino-specific; the question is whether this bug is in our code, or in Widget:Cocoa code. Given the poking that Chris and I did tonight on bug 363577, my bet is on the latter, but I don't know how webloc drags are being handled to say that with 100% certainty....
I just noticed on today's nightly trunk build that dragging a .webloc file to Camino's main window, causes Camino to spin with 100% CPU. I took a sample and will attach it here.
Moving to Cocoa widget and requesting 1.9 blocking, as it's a serious regression. Josh, this used to fall into the kURLDataMime/kURLDescriptionMime block (line 605 of the old nsDragService.cpp), presumably because of the mime mapping (nsMimeMapper.cpp), as text/x-moz-url-data. The new DnD code has no URL type handling at all, which is obviously the source of the regression.
Assignee: nobody → joshmoz
Component: Drag & Drop → Widget: Cocoa
Product: Camino → Core
QA Contact: drag.drop → cocoa
Target Milestone: Camino2.0 → ---
Assignee: joshmoz → stanshebs
Flags: blocking1.9? → blocking1.9+
Target Milestone: --- → mozilla1.9 M10
Created attachment 285952 [details] [diff] [review] handle url-related mime types
The patch seems too simple, but empirically it does all the right things, presumably because pasteboards are a more uniform mechanism, and so it suffices just to get the urls in as if they were text strings, relying on other code later to recognize them correctly by flavor in the transferable.
Comment on attachment 285952 [details] [diff] [review] handle url-related mime types Yep, the old code just pulled out the URL as text too, so that makes sense. r=smorgan
Attachment #285952 - Flags: review?(stuart.morgan) → review+
Attachment #285952 - Flags: superreview?(roc) → superreview+
Comment on attachment 285952 [details] [diff] [review] handle url-related mime types a=drivers for after M9 freeze
Attachment #285952 - Flags: approval1.9? → approval1.9+
landed on trunk
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.