-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[HOLD for payment 2023-08-08] [$1000] Web - The Not Allowed sign is not shown when dragging & dropping attachments if the settings or search bar is open #22305
Comments
Triggered auto assignment to @michaelhaxhiu ( |
Bug0 Triage Checklist (Main S/O)
|
ProposalPlease re-state the problem that we are trying to solve in this issue.Web - The Not Allowed sign is not shown when dragging & dropping attachments if the settings or search bar is open What is the root cause of that problem?The current behaviour of dragover event datatransfer dropeffect is "copy" on setting screens. What changes do you think we should make in order to solve the problem?We need to add a eventlistner for dragover and set e.datatransfer.dropeffect = "none" in callback function when the right sidebar renders Ref- https://codepen.io/SitePoint/pen/epQPNP Here is What we need to do:
only on web we apply the eventListner. on Native it will render the children only similar to what we have Done with DropZone component. // /components/DragAndDrop/NoDropZone/index.js
import { useEffect } from 'react';
import PropTypes from 'prop-types';
const propTypes = {
/** Content */
children: PropTypes.node.isRequired,
};
function NoDropZone(props) {
useEffect(() => {
document.addEventListener('dragover', handleDragOver);
return () => {
document.removeEventListener('dragover', handleDragOver);
};
}, []);
function handleDragOver(event) {
event.preventDefault();
event.dataTransfer.dropEffect = 'none';
}
return props.children;
}
NoDropZone.displayName = 'NoDropZone';
NoDropZone.propTypes = propTypes;
export default NoDropZone; // /components/DragAndDrop/NoDropZone/index.native.js
const NoDropZone = (props) => props.children;
NoDropZone.displayName = 'NoDropZone';
export default NoDropZone;
Result- https://www.loom.com/share/301ba3610bc845fda18b3c0fa977335b?sid=39f313e6-45e8-41a8-9ede-9fa251cd3a0e What alternative solutions did you explore? (Optional)we can add a eventlistner for both dragover and drop and event.preventDefault() on both listners it fails the drop gracefully(no new Tab opens) but the native cursor style for drop not-allowed (🚫 with white box) of windows, it still shows |
@michaelhaxhiu Huh... This is 4 days overdue. Who can take care of this? |
Job added to Upwork: https://www.upwork.com/jobs/~010c9a4080884f501d |
Current assignee @michaelhaxhiu is eligible for the External assigner, not assigning anyone new. |
Triggered auto assignment to Contributor-plus team member for initial proposal review - @Santhosh-Sellavel ( |
This is indeed External, but I don't agree with the
What would be the best UX when dragging & dropping a file with the RHN/chatswitcher expanded? |
Ok I'm gonna take a small step backward, and removing all assignments until we get clear on the Expected Result. I posted on the slack thread to converse further. |
📣 @TopTen1310! 📣
|
✅ Contributor details stored successfully. Thank you for contributing to Expensify! |
@michaelhaxhiu we can either just close the RHN when file is dragged over or show the drop not allowed cursor. |
@michaelhaxhiu Huh... This is 4 days overdue. Who can take care of this? |
@ishpaul777 hmm collapsing the RHN could be a possible option. I feel like we should probably just match what we do on the desktop app ultimately (e.g. it just silently fails, and nothing changes unless you close the RHN). So basically, looking below, we'd potentially remove the behavior from step 4 in bold so web matches desktop?
On other websites, I have seen this exact same kind of behavior whereby a click & drag image upload will open a new tab. I'm not sure if it's fixable on web (as I'm not an engineer) but let's get C+ input too. |
|
The solution for this issue has been 🚀 deployed to production 🚀 in version 1.3.47-6 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue: If no regressions arise, payment will be issued on 2023-08-07. 🎊 After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.
For reference, here are some details about the assignees on this issue:
As a reminder, here are the bonuses/penalties that should be applied for any External issue:
|
BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:
|
So this will dock the pay due to the regression, unfortunately. (cc @michaelhaxhiu) Technically the 7 days also resets, though that's moot here since I think it was the same day |
Understood! Thanks for clarification. |
Triggered auto assignment to @sakluger ( |
Note: I'm preparing to go OOO for ~2 weeks and need a BZ buddy to watch over this in the meantime. 🙏 Next steps:
I'll take this over when I return if it's not complete. Thanks in advance @sakluger |
@michaelhaxhiu according to guidelines, isn't it just dock the speed bonus because of regression, i couldn't find the penalty for regression in docs |
|
found it! I beleive this is added recently so i missed it! Thanks @michaelhaxhiu |
I went ahead and paid @daveSeife for the bug report today. Tomorrow is the payment date for the rest assuming no more issues arise. @robertKozik could you please complete the BugZero checklist (GH comment) when you have some time so that we can close this issue out after payment? Thanks! |
@sakluger I have received the payment, thank you! |
@sakluger I'm not sure whether I filled it right, as this issue was not fixing any regression (only caused one 🥲). Ping me if it should be filled another way
Edited |
So you're right about it not being a regression, I believe. For the regression test, we might want to add one though - basically the testing steps in this issue. Thanks! |
Bump @sakluger for pay reminder. Thanks! |
Completed payment including 50% penalty for the regression. @robertKozik thanks for filling out the checklist and writing out regression steps, looks perfect! |
If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!
Action Performed:
Expected Result:
Not allowed sign is not shown
Actual Result:
Not allowed sign is shown
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Version Number: 1.3.36-4
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Test57_Drag.Drop-1.mp4
Recording.3434.mp4
Expensify/Expensify Issue URL:
Issue reported by: @daveSeife
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1688503808253309
View all open jobs on GitHub
Upwork Automation - Do Not Edit
The text was updated successfully, but these errors were encountered: