[NO PAYMENT NEEDED] Desktop - Unable to move click>dragging the header in desktop app

[kbecciv]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Clicked on the header in the desktop app, held it and tried to move the window by dragging it.

Expected Result:

App to move around like other windows

Actual Result:

App doesn't move around, or only moves around if you click above LHN (I've experienced it both ways)

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.3.42-18
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

2023-07-20_13-48-24.1.mp4

Expensify/Expensify Issue URL:
Issue reported by: @mallenexpensify
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1689713770804419

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @jliexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[allroundexperts]

To reproduce this accurately, you just have to scroll the report such that a report item is behind the report header. Once in this scroll position, the window can not be dragged.

This happened after #21885 was merged. Specifically, adding this line is the culprit here. More details in this comment.

The regression period for above is ending today. Since this issue was reported on Slack before today, I think the original PR author should be fixing this.

[jliexpensify]

Nice, thanks for the input @allroundexperts ! @Skalakid and @Santhosh-Sellavel - going to assign this issue to you as it's a regression (?) cc @conorpendergrast in case you need to adjust payments and @roryabraham as the Engineer who was assigned.

[melvin-bot]

@jliexpensify, @roryabraham, @Santhosh-Sellavel Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[Santhosh-Sellavel]

@Skalakid Can you take care of this please, thanks!

[roryabraham]

Spent a bit of time on this. Electron changed so that pressables must have the webkit-no-drag class, and I'm not sure there's a straightforward way to address this.

I'm not sure this is really a bug worth fixing, since you can drag anywhere near the top, just not over any pressable items in the header. For example, the whole red area is not draggable:

Overall I think the best solution for this problem would be to change HeaderView like so:

desktop.mov

Where the white area is a regular view where the current <PressableWithoutFeedback> is with the same styles, and each individual pressable item is wrapped with a PressableWithoutFeedback w/o any styles, such that you have to actually tap on or near the name or avatar to open the profile page, but if you click anywhere else you can drag the window.

[allroundexperts]

@roryabraham I don't think that its just the red area. If you scroll the chat in the screenshot such that the IOUPreview message is behind the header bar, it becomes virtually impossible to drag the screen.

[allroundexperts]

The real issue IMO here is that there is no stacking order of the webkit-no-drag styles. For example, consider two elements overlapping with each other. Using CSS, we can specify which one comes at top by using z-index. However, if the same elements have different webkit-no-drag properties set, the webkit-no-drag property of the element with higher z-index does not take precedence. Rather, the element with webkit-no-drag set as no-drag takes precedence regardless if the element is hidden behind the element with webkit-no-drag: drag.

[roryabraham]

hmmm ok, well there may be another alternative:

1. Listen to mousemove in BaseGenericPressable
2. If the mouse moves while the pressable is in a pressed state, then we'll want to "manually" adjust the position of the window accordingly.
3. Keep track of the window's current position using electron's win.getPosition API
4. Adjust the window according to the change in mouse position using win.setPosition API.

Note that the browserWindow APIs are in the main process, so we'll need to use IPC + send events across the context bridge from the renderer process, so I'm skeptical that we'll be able to do in a performant way / without jankiness in the drag gestures.

[allroundexperts]

This video might help you understand the issue better.

Screen.Recording.2023-07-25.at.5.10.17.AM.mov

I do agree that this is not easy to fix.

[jliexpensify]

Not overdue!

[Santhosh-Sellavel]

@Skalakid Bump

[Skalakid]

@Santhosh-Sellavel sorry for the delay, I missed notification about this issue. I'll get into that

[Skalakid]

According to Electron documentation, only the buttons in the draggable area should be marked ad no-draggable:

And note that if you have made the whole window draggable, you must also mark buttons as non-draggable, otherwise it would be impossible for users to click on them

So I think there is no need to put no-drag on all buttons. I propose setting the nativeID='no-drag-area' only for the Pressables inside the draggable area, which are:

• HeaderView
• SidebarLinks
• BaseVideoChatButtonAndMenu
• ThreeDotsMenu
• PinButton

After these changes, there should not be problems with dragging the desktop app widow. What do you think about it @Santhosh-Sellavel @roryabraham?

[roryabraham]

Makes sense to me @Skalakid 👍🏼

Alternatively, since this is very browser-specific we could maybe just use a css selector to apply the webkit-no-drag style to any pressable that's a descendent of a draggable div. That way this gotcha wouldn't need to be managed as much by developers in the future

[Skalakid]

@roryabraham that's a good idea. In this case, we should tag all pressable components with some kind of label to access them from CSS. For example, we can set data-id or data-tag to be equal to pressable, and then access it by adding
#drag-area [data-tag="pressable"]. Alternatively, we can add something like that:

  #drag-area {
      -webkit-app-region: drag;
  }
  #no-drag-area, #drag-area [class*="touchAction"] {
      -webkit-app-region: no-drag;
  }

since all Pressables have touchAction class in html

[jliexpensify]

Not overdue!

[melvin-bot]

This issue has not been updated in over 15 days. @jliexpensify, @roryabraham, @Santhosh-Sellavel eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[Santhosh-Sellavel]

We are close to merging the PR!

[roryabraham]

Merged

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.3.59-5 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• 23298 - Desktop - Unable to move click>dragging the header in desktop app #24098

If no regressions arise, payment will be issued on 2023-09-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.

• External issue reporter
• Contributor that fixed the issue
• Contributor+ that helped on the issue and/or PR

For reference, here are some details about the assignees on this issue:

• @Santhosh-Sellavel does not require payment (Eligible for Manual Requests)

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

• Merged PR within 3 business days of assignment - 50% bonus
• Merged PR more than 9 business days after assignment - 50% penalty

[melvin-bot]

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:

• [@Santhosh-Sellavel] The PR that introduced the bug has been identified. Link to the PR:
• [@Santhosh-Sellavel] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@Santhosh-Sellavel] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@Santhosh-Sellavel] Determine if we should create a regression test for this bug.
• [@Santhosh-Sellavel] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@jliexpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[Santhosh-Sellavel]

@jliexpensify No payment due here as this is a regression!

[Santhosh-Sellavel]

@roryabraham I think we can skip the checklist, as all parties are aware of mistakes. I think we don't need a regression test for this one. Should we start a discussion about it?

[roryabraham]

Sounds good to me. This was really a one-off issue that stemmed from breaking changes in Electron, so not much to learn here other than "oops we missed that in testing"