Skip to content
This repository was archived by the owner on Feb 22, 2023. It is now read-only.

Conversation

@kristoffer-zliide
Copy link

@kristoffer-zliide kristoffer-zliide commented Apr 28, 2022

Allowing use of the Link widget in lists with mouse drag enabled.

In a desktop web browser, links are be default draggable. If they are put in e.g. a list, then that list cannot be scrolled by dragging it with the mouse. This PR makes it possible to disable this behavior.

Issues fixed: #102735

Pre-launch Checklist

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I read the Tree Hygiene wiki page, which explains my responsibilities.
  • I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
  • I signed the CLA.
  • The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
  • I listed at least one issue that this PR fixes in the description above.
  • I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
  • I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style.
  • I updated/added relevant documentation (doc comments with ///).
  • I added new tests to check the change I am making, or this PR is test-exempt.
  • All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

allowing use of the Link widget in lists with mouse drag enabled.
@google-cla
Copy link

google-cla bot commented Apr 28, 2022

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

For more information, open the CLA check for this pull request.

@stuartmorgan-g
Copy link
Contributor

@ditman Ping on this review?

@ditman
Copy link
Member

ditman commented May 21, 2022

Apologies! I'm going to bump this to @mdebbar, he knows the Link widget much better than I do.

Mouad, do you mind taking a look? Thanks!!

@ditman ditman requested a review from mdebbar May 21, 2022 00:46
@stuartmorgan-g
Copy link
Contributor

From triage: @mdebbar Ping on this review.

Copy link
Contributor

@mdebbar mdebbar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PR looks good to me. I would like for @ditman to take a look at the pubspec changes since I'm not very familiar with how plugin dependencies are supposed to be.

Comment on lines +11 to +17
url_launcher:
path: ../../url_launcher/
dependency_overrides:
url_launcher_web:
path: ../
url_launcher_platform_interface:
path: ../../url_launcher_platform_interface/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ditman I'm not qualified to review this part of the PR. Could you take a look?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will need to be reverted so we can merge and publish the affected packages in the correct order.

Copy link
Member

@ditman ditman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We cannot merge this PR as is, because we now need to update version and CHANGELOG of the affected packages. Could you prepare a separate PR for each of the packages, so we can merge and publish them in order?

Comment on lines +250 to +259
_element.style
// Chrome
..userDrag = 'none'
// Edge
..setProperty('-webkit-user-drag', 'none');
// Firefox
_element.draggable = false;
_dragSubscription = _element.onDragStart.listen((event) {
event.preventDefault();
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was checking caniuse.com, and it seems that:

  • there's no unprefixed user-drag property. Docs.
  • wouldn't draggable = false be enough?

Also, if disabling drag in the element, is it necessary to stop the default drag event?

I think this method could be much simplified to be just _element.draggable = false?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems you're close to being right. We started out with the styling approach since it allowed us to apply a global work-around in index.html (<style>a { -webkit-user-drag: none; }</style>). Probably just added user-drag since it was right there in html_dart2js.dart, and if it works, it's nicer than the -webkit- style. But it also seems that draggable works on both Chrome and Edge; however, I couldn't make it work on Firefox without preventDefault. In the end, I guess it's a matter of taste: Do you want style or properties for this? Do you want to wrap the drag subscription in some Firefox shim?

Copy link
Member

@ditman ditman Jun 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After some tests, it seems that the only solution that seems to work the same across all platforms is preventDefault on the dragstart event. See:

If draggable=false, none of the browsers will trigger a dragstart event (as expected).

In Firefox, draggable=false works (it won't let you drag the Link), but it'll also start selecting from the text of the link as the user drags (which I guess is what you couldn't get to work?). This is a firefox quirk, but I couldn't find anything relevant in their bug tracker.

Copy link
Member

@ditman ditman Jun 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(My second favorite version might be draggable=false and if the browser is firefox, prevent the selectstart event (draggable=false + no selectstart in the JSFiddle), which doesn't interfere with the selection from the outside as much as user-select in CSS does!)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, what we couldn't get to work is the issue I linked to: links in a list. For that case preventing select start doesn't seem to be sufficient. But interactions with text selection should indeed probably also be considered.

Comment on lines +11 to +17
url_launcher:
path: ../../url_launcher/
dependency_overrides:
url_launcher_web:
path: ../
url_launcher_platform_interface:
path: ../../url_launcher_platform_interface/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will need to be reverted so we can merge and publish the affected packages in the correct order.

@stuartmorgan-g
Copy link
Contributor

Could you prepare a separate PR for each of the packages, so we can merge and publish them in order?

We actually just do this one at a time; see https://github.com/flutter/flutter/wiki/Contributing-to-Plugins-and-Packages#changing-federated-plugins

So the next step is to make just the platform interface PR, then once that lands, the implemenation package PR, then finally rebase this one.

@stuartmorgan-g
Copy link
Contributor

@kristoffer-zliide Are you planning on splitting out the platform interface PR, as described above?

@kristoffer-zliide
Copy link
Author

@stuartmorgan: Yeah, but I'm not sure if we've reached a conclusion on this: https://github.com/flutter/plugins/pull/5430/files#r896078916. I can make pull requests that adds draggable and preventDefault (ie, what's done for Firefox here: https://github.com/flutter/plugins/pull/5430/files#diff-77a04b3b00b00a4480b7d5e75e089dde7cca99ccebcc4f43e0e25d2bba5346e0R255), then you can always tweak it to your heart's content afterwards?

@stuartmorgan-g
Copy link
Contributor

@ditman You marked this as approved; what was your take on the resolution of that comment thread?

@ditman
Copy link
Member

ditman commented Jul 15, 2022

@ditman You marked this as approved; what was your take on the resolution of that comment thread?

@stuartmorgan let's go with the solution as implemented. I did some testing and indeed for cross-browser support, you need more than one approach, as @kristoffer-zliide correctly pointed out.

Apologies I wasn't more clear in that regard!

@stuartmorgan-g
Copy link
Contributor

@kristoffer-zliide It sounds from the above like this was ready for a platform interface PR; are you still planning on splitting that out to move this forward?

@kristoffer-zliide
Copy link
Author

@stuartmorgan: here you go

@stuartmorgan-g
Copy link
Contributor

Status update from triage: blocked on resolving the breaking change issue in #6282.

@stuartmorgan-g
Copy link
Contributor

Status from triage: still blocked on #6282

@stuartmorgan-g
Copy link
Contributor

Since this is still blocked on the other PR, I'm going to go ahead and mark this as a draft just to avoid having it come up in our triage queue. Once the blocking issue is resolved, this can be marked as ready for review again.

@stuartmorgan-g stuartmorgan-g marked this pull request as draft October 27, 2022 20:16
@stuartmorgan-g
Copy link
Contributor

Closing since #6282 is now closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Proposal][url_launcher][web] Allow draggable behaviour of Link to be configurable.

4 participants