Closed Bug 1291884 Opened 5 years ago Closed 5 years ago

Drag and Drop not working in DOM Inspector

Categories

(Other Applications :: DOM Inspector, defect)

defect
Not set
normal

Tracking

(seamonkey2.44 unaffected, seamonkey2.45 unaffected, seamonkey2.46 unaffected, seamonkey2.47 verified, seamonkey2.48 verified)

VERIFIED FIXED
mozilla50
Tracking Status
seamonkey2.44 --- unaffected
seamonkey2.45 --- unaffected
seamonkey2.46 --- unaffected
seamonkey2.47 --- verified
seamonkey2.48 --- verified

People

(Reporter: frg, Assigned: frg)

References

Details

Attachments

(1 file)

DOM Inspector still uses the legacy Drag and Drop observers which were removed in Bug 1162050.
While not necessary I also renamed the methods for continuity.

Brief test with Seamonkey 2.48a1 was ok but I don't know the extention very well.
Assignee: nobody → frgrahl
Status: NEW → ASSIGNED
Attachment #8778695 - Flags: review?(philip.chee)
Comment on attachment 8778695 [details] [diff] [review]
1291884-DragDropFix.patch

What's the minimum version of Gecko that supports ondragstart/ondrop? We may need to bump the minimum application version in the install.rdf
Attachment #8778695 - Flags: review?(philip.chee) → review+
Release note: Bug 1291500 comment #17 will apply here too. The "mutatis mutandis" is of course that the XPI to be manually installed from distribution/extensions/ is of course named inspector@mozilla.org.xpi and not {59c81df5-4b7a-477b-912d-4e0fdf64e5f2}.xpi
Done and tag DOMI_2_0_16_GECKO_45 also moved:

https://hg.mozilla.org/dom-inspector/rev/e984fe736d21
https://hg.mozilla.org/dom-inspector/rev/3be1948e3f0b
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Well, now I've installed the following SeaMonkey:

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48a1
Build identifier: 20160808154736
http://hg.mozilla.org/mozilla-central/rev/720b5d2c84d5b253d4dfde4897e13384dc97a46a
http://hg.mozilla.org/comm-central/rev/f7e1f4d6f62f

(Note that due to lack of interest for bug 825549 in 3½ years, I can't be sure of the DOMi changeset used for building this .tar.bz2)

and then I've installed its distribution/extensions/inspector@mozilla.org.xpi into its profile… BUT: How do I test this fix? What can be dragged and dropped in DOMi?

I _can_ drag the two pane boundaries about with the mouse to change pane sizes. If this is what couldn't be done since bug 1162050 landed, then the bug is verified-fixed. Or is there more to DOMi D&D than just resizing the panes?
OS: Unspecified → All
Hardware: Unspecified → All
Version: unspecified → Trunk
irc://moznet/seamonkey
frg_away >	tonymec|away: Hi Tony, you can drag and drop an url to DOMi. Didn't work before the patch.

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48a1
Build identifier: 20160809003002
http://hg.mozilla.org/mozilla-central/rev/720b5d2c84d5b253d4dfde4897e13384dc97a46a
http://hg.mozilla.org/comm-central/rev/adc56f0cd5b5

After installing this (today's) nightly, reinstalled /usr/local/seamonkey/distribution/extensions/inspector@mozilla.org.xpi into the profile (and restarted) in order to be 100% sure that my current DOMi was made after the fix landed.

Dragging the favicon in the browser's URL bar to DOMi's URL bar displays the URL in the latter; then the "Inspect" button opens the page in a "Browser" pane at the bottom of the DOMi window.

However, AFAICT the DOMi URL bar is not cleared first and the URL is "dropped" wherever the I-bar "insertion cursor is in the DOMi URL bar when the mouse button is released, possibly inserting the new URL in the middle of an existing URL, so the DOMi URL bar may have to be manually cleared first.

With this caveat:
1. Works for https://bugzilla.mozilla.org/show_bug.cgi?id=1291884#c6
2. Works for about:
3. Works for chrome://lwthemes/content/lwthemes.xul from the "Lightweight Themes Manager" extension
4. Works for file:///root/pub/slovarj/ru-fr.05.html#zzz on my own HD

I haven't found out how to inspect the browser chrome this way (other than by first loading its chrome URL in a window); I'm not sure it is possible.

Comparison of the "current" (not "tip") revisions from ./mozilla/extensions/inspector/ inside my comm-central and comm-aurora clones shows that the same changes have been brought into both.

=> VERIFIED.
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla50
You need to log in before you can comment on or make changes to this bug.