Kevin Grandon :kgrandon Reporter
	Description • 9 years ago

In bug 1118169 window-dragging was implemented as a CSS hook to allow calling users to drag HTML windows. In recent builds of Firefox it appears to have stopped working. 

In the CSS console, I'm seeing: Unknown property '-moz-window-dragging'.  Declaration dropped.

	Kevin Grandon :kgrandon Reporter
	Comment 2 • 9 years ago

Likely a regression from this commit range: https://github.com/mozilla/gecko-dev/compare/ca77b70a8dec768e6b1e09371ee666d523f9f4b1...399a23b6c1ec9441a9a1b3b9b2bcb4d78fcb0a40

	Mats Palmgren (inactive)
	Comment 3 • 9 years ago

An effect of bug 1211040 most likely.

	Kevin Grandon :kgrandon Reporter
	Comment 4 • 9 years ago

Yes, looks like this was caused by bug 1211040. 

It appears that bug 1211040 broke -moz-window-dragging usage for Graphene which was being used for b2g desktop like runtimes where the chrome is written in HTML. Can we possibly restore this property, or expose it based on a permission?

	Kevin Grandon :kgrandon Reporter
	Comment 5 • 9 years ago

We set a property here which is supposed to allow us to enable window dragging: http://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js#403

webNav.QueryInterface(Ci.nsIDocShell).windowDraggingAllowed = true;

	Xidorn Quan [:xidorn] UTC+11 Assignee
	Comment 6 • 9 years ago

Could you provide a link to the code where you use this property?

	Kevin Grandon :kgrandon Reporter
	Comment 7 • 9 years ago

(In reply to Xidorn Quan [:xidorn] (UTC+10, no dst) from comment #6)
> Could you provide a link to the code where you use this property?

It will be assigned to HTML elements which are considered to be the chrome of the application. The application is generally a certified app, and in the past we enabled usage of this property via windowDraggingAllowed. It seems that setting this property no longer works.

This may not be too clear, but here is an example of where it can be set through JS: https://github.com/mozilla/browser.html/blob/287afcd0fc8765152d13a861d478ed8513bfc13a/src/browser/window-bar.js#L17

	Xidorn Quan [:xidorn] UTC+11 Assignee
	Comment 8 • 9 years ago

This property should be usable in chrome code, so if the page which uses this is loaded from chrome:// scheme, it ought to work.

However, there are two additional limitations after that bug:
1. the property is not accessible via CSSOM, so you cannot set or get `element.style.mozWindowDragging`;
2. the property isn't parsed when it is used in inline style, so `<div style="-moz-window-dragging: drag">` doesn't work.

But it should work if you use that inside a <style> or a CSS file.

Since the code you provide interact with reflex, which I'm not quite familiar with, I'm not sure which limitation did you meet. From the comment 0, I guess it is the second one. We can probably try to remove the that limitation if that makes sense to your case.

	Kevin Grandon :kgrandon Reporter
	Comment 9 • 9 years ago

(In reply to Xidorn Quan [:xidorn] (UTC+10, no dst) from comment #8)
> This property should be usable in chrome code, so if the page which uses
> this is loaded from chrome:// scheme, it ought to work.
> 
> However, there are two additional limitations after that bug:
> 1. the property is not accessible via CSSOM, so you cannot set or get
> `element.style.mozWindowDragging`;
> 2. the property isn't parsed when it is used in inline style, so `<div
> style="-moz-window-dragging: drag">` doesn't work.
> 
> But it should work if you use that inside a <style> or a CSS file.
> 
> Since the code you provide interact with reflex, which I'm not quite
> familiar with, I'm not sure which limitation did you meet. From the comment
> 0, I guess it is the second one. We can probably try to remove the that
> limitation if that makes sense to your case.

With react we're running into the first limitation most likely. What was the reasoning for introducing it?

In addition, we need to be able to access this from non-chrome code. As I said, previously this was allowed from the windowDraggingAllowed docshell property in non-chrome code. Can we restore that behavior and allow window dragging in non-chrome code if windowDraggingAllowed is set? If not, can we allow it for non-chrome code in certified apps? I believe only chrome privilieged code should be able to set the windowDraggingAllowed property.

	Kevin Grandon :kgrandon Reporter
	Comment 10 • 9 years ago

Please see this thread for more context: https://bugzilla.mozilla.org/show_bug.cgi?id=1118169#c13

	Xidorn Quan [:xidorn] UTC+11 Assignee
	Comment 11 • 9 years ago

If it is useless in content even if it is exposed... I guess it's ok to restore the behavior. dbaron, WDYT?

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 12 • 9 years ago

(In reply to Xidorn Quan [:xidorn] (UTC+10, no dst) from comment #11)
> If it is useless in content even if it is exposed...

I don't understand.  In what sense is it useless in content?  (If so, how was there a regression here?)

Or do you need to revisit bug 1069192 comment 12 and conditionally expose the DOM properties when the property works?

	Kevin Grandon :kgrandon Reporter
	Comment 13 • 9 years ago

> I don't understand.  In what sense is it useless in content?  (If so, how was there a regression here?)

I think it's useless in content unless the docshell is flagged from privileged code. In most content that will never be the case, so the property will be useless in those cases.

Xidorn, please correct me if that's not the case.

Is backing bug 1211040 out possible? I hate to ask when there's no tests that caught this, but I will file a bug to write a test for moz-window-dragging and the Graphene runtime.

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 14 • 9 years ago

Yeah, I think backing out is fine.  (Or should it be half backed out?)

	Xidorn Quan [:xidorn] UTC+11 Assignee
	Comment 15 • 9 years ago

(In reply to David Baron [:dbaron] ⌚UTC-7 from comment #12)
> (In reply to Xidorn Quan [:xidorn] (UTC+10, no dst) from comment #11)
> > If it is useless in content even if it is exposed...
> 
> I don't understand.  In what sense is it useless in content?  (If so, how
> was there a regression here?)

As kgrandon said in comment 13, they use a flag in docshell to control the effectiveness of this property, and docshell is only accessible via the chrome code, so it is useless for general web content.

> Or do you need to revisit bug 1069192 comment 12 and conditionally expose
> the DOM properties when the property works?

They said they want to allow it in not only chrome code, but also certificated apps, so conditionally exposing the DOM property probably won't work for them either. (see last paragraph in comment 9)

(In reply to David Baron [:dbaron] ⌚UTC-7 from comment #14)
> Yeah, I think backing out is fine.  (Or should it be half backed out?)

I'm going to have a patch to re-expose this single property. I don't see any reason for re-exposing the other property in that patch.

	Xidorn Quan [:xidorn] UTC+11 Assignee
	Comment 16 • 9 years ago

Bug 1212607 - Re-expose -moz-window-dragging property to the content.

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 17 • 9 years ago

Comment on attachment 8671691 [details]
MozReview Request: Bug 1212607 - Re-expose -moz-window-dragging property to the content.

https://reviewboard.mozilla.org/r/21631/#review19435

	Xidorn Quan [:xidorn] UTC+11 Assignee
	Comment 18 • 9 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/40f2d8c486bfdc6201a5bab9131a833d0c60269f
Bug 1212607 - Re-expose -moz-window-dragging property to the content. r=dbaron

	Kohei Yoshino [:kohei]
	Comment 19 • 9 years ago

Updated the site compatibility doc accordingly. https://www.fxsitecompat.com/en-US/docs/2015/several-internal-css-properties-have-been-removed/

	Carsten Book [:Tomcat]
	Comment 20 • 9 years ago

https://hg.mozilla.org/mozilla-central/rev/40f2d8c486bf