Graphite Community

Thanks Ben! This may impact submitting PRs via the CLI as well as the Graphite dashboard.  We're monitoring closely and expect Graphite to work as normal as soon as GitHub is operational again.

unfortunately we don't have longer-term fix for this one yet aside from the workaround you mentioned, i am planning to tackle it in the next few months. sorry about that!

that blue progress bar at the top has stopped inching along, and there's no timeout or anything... just forever stuck

Hi <@U045W8WMUN5>, taking a look now! From our logs, I think we’ve hit a global GitHub rate limit for file loads on our IP.

yikes! OK, hoping you can work out a resolution soon. Thanks for the quick reply!

might be worth a post in general or something

Just an update <@U045W8WMUN5>, this appears to be resolved!

Seems like it's back, unfortunately <@U02DGG36CSH>

OK, this time it took about 3 minutes to load... it didn't hang forever, so... false alarm, kinda?

Ah still not ideal :disappointed: Do you mind sending me PR that this happened on? I can take a look and dig into what might have been happening.

I don't remember which one, but I'll send somethign over if this happens again. Thank you!

Graphite - PR files failing to load ​*[Investigating]*​ We are currently investigating this incident.
 ​*Affected:*​
Dashboard,
 View incident button

Graphite - PR files failing to load ​*[Resolved]*​ This incident has been resolved.
 ​*Affected:*​
Dashboard,
 View incident button

Thanks for this feedback, <@U02DCQ1C0G6>, <@U04AP0M9AES>, <@U04GQFJNDC7>, and I will put our heads together here :slightly_smiling_face:

I just started seeing this today.  Have to go to github to respond to comments…

Thanks for reporting, we've identified a likely cause and are reverting

Did y’all add a test case for this?  seems like a pretty common usecase.

hey folks, wanted to provide some context: im working on improving our commenting infrastructure and mistakenly released some changes before they were ready which caused this incident

we take this very seriously and are taking steps to ensure that similar issues don't happen in the future

thank you for bearing with us as we iterate here and we really appreciate your feedback!

why.mov

We're reverting the bad change! Sorry about this

<https://graphite-community.slack.com/archives/C02DRNRA9RA/p1688147852405189?thread_ts=1688147075.872709&amp;cid=C02DRNRA9RA>

Our production deploy of the fix should be out in a few minutes! Sorry for the inconvenience

CleanShot 2023-07-02 at 15.04.04@2x.png

Thanks for reporting! yeah looks like there might’ve been a regression to the stack visualization. Filing a ticket

im taking a look here! if you go to your preferences and hard refresh the page, what does the color selector say?

It currently says “Light”, which is correct, but my experience has been that it stays “Light” for an hour or so before resetting back to “Dark”.

weird… and at that point the selector shows `Dark` ?

That has been my experience. It is working now of course, but I’ve been having this issue for about a week. Before that I just had it set to whatever the default was as I was not using the web UI at all.

got it, thanks for the info! i’ll dig into this on my end to make sure this doesn’t continue to happen — but if it happens again please let me know what that selector says

```➜  stackrox git:(master-janisz/06-30-ROX-18155_pg_generic_store_Exists) gt ss
🥞 Validating that this Graphite stack is ready to submit...

✏️  Preparing to submit PRs for the following branches...
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Exists (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Count (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Walk (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetAll (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Get (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetByQuery (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetIDs (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetMany (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_DeleteByQuery (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Delete (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_DeleteMany (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_regions (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_cleanup (Update)

📨 Pushing to remote and creating/updating PRs...
master-janisz/06-30-ROX-18155_pg_generic_store_Exists: <https://app.graphite.dev/github/pr/stackrox/stackrox/6766> (updated)
master-janisz/06-30-ROX-18155_pg_generic_store_Count: <https://app.graphite.dev/github/pr/stackrox/stackrox/6767> (updated)
master-janisz/06-30-ROX-18155_pg_generic_store_Walk: <https://app.graphite.dev/github/pr/stackrox/stackrox/6768> (updated)
master-janisz/06-30-ROX-18155_pg_generic_store_GetAll: <https://app.graphite.dev/github/pr/stackrox/stackrox/6769> (updated)
ERROR: Unexpected server response (500).

Response: {
  "_response": {
    "size": 0,
    "timeout": 0
  }
}
➜  stackrox git:(master-janisz/06-30-ROX-18155_pg_generic_store_Exists) gt ss
🥞 Validating that this Graphite stack is ready to submit...

✏️  Preparing to submit PRs for the following branches...
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Exists (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Count (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Walk (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetAll (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Get (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetByQuery (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetIDs (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetMany (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_DeleteByQuery (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Delete (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_DeleteMany (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_regions (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_cleanup (Update)

📨 Pushing to remote and creating/updating PRs...
master-janisz/06-30-ROX-18155_pg_generic_store_GetByQuery: <https://app.graphite.dev/github/pr/stackrox/stackrox/6771> (updated)
master-janisz/06-30-ROX-18155_pg_generic_store_GetIDs: <https://app.graphite.dev/github/pr/stackrox/stackrox/6772> (updated)
master-janisz/06-30-ROX-18155_pg_generic_store_GetMany: <https://app.graphite.dev/github/pr/stackrox/stackrox/6773> (updated)
master-janisz/06-30-ROX-18155_pg_generic_store_DeleteByQuery: <https://app.graphite.dev/github/pr/stackrox/stackrox/6774> (updated)
ERROR: Unexpected server response (500).

Response: {
  "_response": {
    "size": 0,
    "timeout": 0
  }
}
➜  stackrox git:(master-janisz/06-30-ROX-18155_pg_generic_store_Exists) gt ss
🥞 Validating that this Graphite stack is ready to submit...

✏️  Preparing to submit PRs for the following branches...
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Exists (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Count (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Walk (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetAll (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Get (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetByQuery (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetIDs (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetMany (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_DeleteByQuery (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Delete (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_DeleteMany (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_regions (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_cleanup (Update)

📨 Pushing to remote and creating/updating PRs...
ERROR: Unexpected server response (500).

Response: {
  "_response": {
    "size": 0,
    "timeout": 0
  }
}
➜  stackrox git:(master-janisz/06-30-ROX-18155_pg_generic_store_Exists) gt ss
🥞 Validating that this Graphite stack is ready to submit...

✏️  Preparing to submit PRs for the following branches...
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Exists (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Count (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Walk (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetAll (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Get (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetByQuery (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetIDs (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetMany (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_DeleteByQuery (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Delete (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_DeleteMany (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_regions (Update)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_cleanup (Update)

📨 Pushing to remote and creating/updating PRs...
ERROR: Unexpected server response (500).

Response: {
  "_response": {
    "size": 0,
    "timeout": 0
  }
}
➜  stackrox git:(master-janisz/06-30-ROX-18155_pg_generic_store_Exists) gt ss
🥞 Validating that this Graphite stack is ready to submit...

✏️  Preparing to submit PRs for the following branches...
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Exists (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Count (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Walk (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetAll (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Get (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetByQuery (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetIDs (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetMany (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_DeleteByQuery (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Delete (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_DeleteMany (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_regions (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_cleanup (Update)

📨 Pushing to remote and creating/updating PRs...
ERROR: Unexpected server response (500).

Response: {
  "_response": {
    "size": 0,
    "timeout": 0
  }
}
➜  stackrox git:(master-janisz/06-30-ROX-18155_pg_generic_store_Exists) gt ss
🥞 Validating that this Graphite stack is ready to submit...

✏️  Preparing to submit PRs for the following branches...
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Exists (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Count (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Walk (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetAll (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Get (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetByQuery (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetIDs (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_GetMany (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_DeleteByQuery (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_Delete (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_DeleteMany (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_regions (No-op)
▸ master-janisz/06-30-ROX-18155_pg_generic_store_cleanup (No-op)

🆗 All PRs up to date.```

I'm also seeing this `Unexpected server response (500)` error with the same response. I'm using graphite for the first time and am seeing it when submitting a stack that has a single PR. Here's the stack trace from `gt ss --debug`
```📨 Pushing to remote and creating/updating PRs...
2023-07-03T22:59:05.165Z: Persisting cache...
ERROR: Unexpected server response (500).

Response: {
  "_response": {
    "size": 0,
    "timeout": 0
  }
}
2023-07-03T22:59:05.292Z: ExitFailed: Unexpected server response (500).

Response: {
  "_response": {
    "size": 0,
    "timeout": 0
  }
}
    at requestServerToSubmitPRs (/snapshot/graphite-cli/apps/cli/dist/src/actions/submit/submit_prs.js)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async submitPullRequest (/snapshot/graphite-cli/apps/cli/dist/src/actions/submit/submit_prs.js)
    at async submitAction (/snapshot/graphite-cli/apps/cli/dist/src/actions/submit/submit_action.js)
    at async Object.run (/snapshot/graphite-cli/apps/cli/dist/src/commands/stack-commands/submit.js:16:9)
    at async graphiteHelper (/snapshot/graphite-cli/apps/cli/dist/src/lib/runner.js)
    at async /snapshot/graphite-cli/apps/cli/dist/src/lib/runner.js
    at async Tracer.span (/snapshot/graphite-cli/apps/cli/dist/src/lib/utils/tracer.js)
    at async graphiteInternal (/snapshot/graphite-cli/apps/cli/dist/src/lib/runner.js)
    at async Object.handler (/snapshot/graphite-cli/apps/cli/dist/src/commands/stack-commands/submit.js:15:5)```

Turns out in my case the 500 was because I had to have the github org approve the graphite app in github Settings &gt; Applications &gt; Authorized OAuth Apps &gt; click graphite &gt; Request the org. The fact that the error code was a 500 made me think it was an issue on graphite's side, so my only feedback here would be to include a better error message, but `gh ss` worked as expected now!

Looking through the sidebar, I found what I was looking for here: <https://graphite.dev/docs/tracking-branches>, but the old page is first on Google and on the site’s internal search.

Probably caused by / related to <https://graphite-community.slack.com/archives/C02DRNL3HQU/p1688170150480819>

Thanks for flagging! I think most of our redirects should be working now

About to update the search results as well

Screenshot 2023-07-04 at 12.22.28 PM.png

this should work (even with only the keyboard!), so if it doesn’t that sounds like a bug
to confirm, you’re talking about selecting one of these rows, right?

Indeed! I’ll try again tomorrow just to verify. 

Verified this is working for me now. Not sure why it didn’t at that time. 

sweet! please let us know if you see that again :slightly_smiling_face:

could you show the output of `rs` with the `--debug` flag?

o i see <https://graphite-community.slack.com/archives/C02DRNRA9RA/p1688070336702399?thread_ts=1688070023.022589&amp;cid=C02DRNRA9RA>

like run `gt rs` without doing the cache part

Hey there! Could you run this with the `--debug` tag? And we'll look into it!

Will do in the future, but it's not 100% reproducible, happens occasionally.

Gotcha. Will look into this further and let you know what could be going on here.

Hey Alex!

  

1. Gotcha - there's a known issue with Graphite/Arc compatibility where having multiple Graphite tabs open at once can lead to infinite loading (arc’s tab suspension preventing an indexdb lock from being released), this could be part of your issue here. This can be solved by pinning a Graphite tab, or going and clicking into another inactive tab if the current one is infinitely loading. Sorry about the latency here, we're looking to resolve this soon! BTW, heard on the GitHub link on the loading screens - we'll see what we can do here!
2. Please send as many bugs/issues you're running into as you can!! We'll do our best to resolve them as they come :)) Your feedback is much appreciated
3. I see - are you talking about the Graphite reminder digests here, or something you've set up separately? If it's the Graphite reminder digests, you should definitely be receiving those through the Graphite DMs and we'll look into why that isn't working for you!
4. Heard on this as well - we have a project on our roadmap to create perma-links to comments in Graphite which we'll update our comment/review/thread notifs to reference when the time comes :))

  

Super appreciate the feedback here and sorry you're Graphite Slack experience hasn't been ideal - feel free to message me personally if there's anything else we can do to help, but really appreciate the feedback here!

no promises but permalinks is likely my next large ish commenting project!

we didn't capture updating the Slack links though so i've made a Linear for myself for that one

In the Graphite Slack notifications settings, you can set up digests on a cadence of your choice to remind you about PRs that you may have missed!

See here: <https://app.graphite.dev/settings/notifications>

This might solve your issue for number 3 :')

Graphite on Arc should be fully working with the fix we pushed last night!

Thanks for pointing this out! Fixing :slightly_smiling_face:

Thanks for reporting! We've noticed this internally too, working on a fix!

It definitely made me doubt my brain's integrity for a moment :brain: :face_with_raised_eyebrow:

Hi there! Did the repo name change recently?

See: <https://graphite-community.slack.com/archives/C02DRNRA9RA/p1686440705318779>

Nope, repo did not change however we did change repo to be enterprise status? Not sure if that could have an effect 

Hmm honestly that could be it - let me check with the team and get back to you!

Hey Salil, are you still having issues here?

I will check the next time someone puts up a stack

Thanks for sharing debug context! We'll look into this for you. Getting 500s on all submits or is it intermittent?

Hmm ok got it - thanks! Could you DM me the PR if possible?

just created a new branch on that repo with an empty commit, tried to submit, same problem

Steps taken (internal things removed)
```❯ gt bc frank.schmager/test
No staged changes; created a branch with no commit.

❯ git commit --allow-empty -m "Empty-Commit"
[frank.schmager/test dd3bb93dc1f6] Empty-Commit

❯ gt ss
🥞 Validating that this Graphite stack is ready to submit...

WARNING: The following branch has no changes:
WARNING: ▸ frank.schmager/test
WARNING: Are you sure you want to submit it?

✔ How would you like to proceed? › Continue with empty branch

✏️  Preparing to submit PRs for the following branches...
▸ frank.schmager/test (Create)
✔ Title … Empty-Commit
✔ Body Template › /PULL_REQUEST_TEMPLATE.md
✔ Body › Skip (paste template)
✔ Submit › Create Draft Pull Request

📨 Pushing to remote and creating/updating PRs...
ERROR: Unexpected server response (500).

Headers:
  x-graphite-request-id: 8db7fab9-d57f-4ef8-a37a-1d9a5692f909

Response: {
  "_response": {}
}```

Hi <@U05F79ELA56>, I took a look in and found a silly bug on our end. I’ll follow up here when the fix is deployed!

Let us know if you keep seeing any issues here :slightly_smiling_face:

the bug is silly no more, well it might still have been silly, but it is no more

`gt ss` succeeds where it previously did not

thanks for the quick fix

I have been running into this issue as well on one of my repos since morning. On another repo when trying to submit the stack I get `504` code

```gt version
0.20.22

node version
v19.2.0

npm version
8.19.3```

image.png

<@U03FNT1FLP5> coming back to this thread, we probably need more context before investigating can occur
what is the PR link?
what were you doing at the time? did you just land on the page and it looked like this? or did _editing_ the PR description cause this to duplicate?
does it look like this on github?

Hey David, yeah this is actually how it looks in GitHub. Afraid I don't have the link to hand, but this happened just from opening the pr. I only entered two lines but nothing else, landed on the Github page and it looked like that 
Haven't seen it since though!

Just updated status page + 2x’d our server pods temporarily

Thanks Greg! Do y'all have alerting when API latency spikes?

We do, cc <@U0486U7UUF3>, but unfortunately datadog metrics from AWS are delayed. So in this case we got paged minutes after you posted here

We have faster metrics from our server APM, but those are sometimes inaccurate for latency specifically - we prefer to measure from load balancer

so our graphs had the spike, but our alert was delayed

latency is coming down, debugging root cause now

Looks like a stray web app (specific user browser tab) ddos’d us momentarily. Excuse me while we tighten up our load balancer rate limits lol

BTW, the bold orange on the notif is a bit extreme in dark mode, though I think it's pretty.

Have the banner colors on my radar! Thanks for reporting

Hi!! Thanns for flagging - this is a known issue and we'll fix it up soon!

We have a few KPs around escape taking you back to the PR inbox when it’s supposed to back out of focus on local UI - it should only take you back to the dashboard if you’re at the top level of focus.  We’re planning to fix those in the next few weeks, and then let’s revisit and see if it feels better?

<@U045W8WMUN5> what contexts are you accidentally hitting esc in?
can you speak more to what you're trying to do when this occurs?

Oh gosh, that's all so sub-conscious. I know i hit the discard changes? modal twice today unexpectedly, and I've been learning to use escape again to get back out of it (though it makes me uneasy every time). I'll try and track how these situations come up and follow up here.

Unrelated: Looks like escape doesn't exit out of the Syntax Highlighting selection menu.

&gt; Unrelated: Looks like escape doesn't exit out of the Syntax Highlighting selection menu.
filed a linear for this one

yeah as soon as you hit any escape issues feel free to dump here

Part of it is that for keyboard shortcut people, it's easy to move fast. If I hit escape, I expect it'd close a modal or an emoji picker, so it's usually safe, and so my fingers don't shy away from it. But with Graphite, if I press it, my _whole world_ disappears, and I have to click in and find my place again. I also have anxiety every time about whether the comments I was writing got lost.

I'll also document other cases if I find them, but that's the trees. The forest is that I don't expect Esc to flip the table upside down.

If y'all decide you really want to leave Esc as a shortcut for going to the main dashboard, please at least consider adding an "are you sure, you'll lose your place" modal if I've scrolled down, or done anything in the PR.

If you really want an esc-like shortcut, maybe consider mapping it to Cmd-Esc, and leaving Esc for closing small ephemeral UI.

Makes sense - you definitely shouldn’t lose any pending comments or edits by navigating back the inbox

I _think_ I don't lose anything (I'm not positive, but I think)... but that's not exactly the issue.

I'm losing scroll position (which is a bit hard to regain while you're working on scroll stability), and I'm losing flow

Flow is the big one, but I'm glad to know that stable and persistent scroll is coming :heart:

I run into this problem pretty frequently since I use vim keybindings. When I click to add a comment and then decide against it, I'll hit escape but I'll often hit it 2-3 times because of vim muscle memory (I usually tap it multiple times to make sure it reads correctly since there is no penalty to doing that in vim) and it drops me back into the PR list.

If I'm remembering right it used to be worse because the escape also handled the delete comment confirmation screen (which it doesn't seem to anymore which is probably good) and I would get dropped to the PR list more often, but now I get locked there if I've written anything

Another situation I ran into. I clicked to add a comment, changed my mind, and then pressed escape a few times. That booted me all the way out to the dashboard and I had to find my place again. Edit: gah, I did it again :neutral_face:

Yes, _technically_ I should only press space once in that situation, but alas, I don't have direct control of my muscle memory.

The fact that some people press `esc` with such reckless abandon is probably because it's safe to do in most applications.

Did it again, this time was weird. I clicked to make a comment, right-clicked, then pressed escape to dismiss the right-click dialog, then escape again to dismiss the empty comment box. That second escape popped be to the dashboard instead of dismissing the comment box.

I got dumped out of a review again today due to a double escaping, this time it was because I was doing a ctr+f search and wanted to end the search

<@U045W8WMUN5> yeah i think if you right clicked out of the box, your `document.activeElement` is the `&lt;body&gt;` and now `esc` will send you to the dashboard

<@U04CXE58V32> and in this case you hit esc 1x too many times right? i'm seeing that at least the find box does handle `esc` if you don't overhit `esc`

Yeah, the issue is I'm hitting it twice instead of once. So not exactly a bug since I think this is how its intended to work, more that it feels less than ideal for me

curious if there are *other users lurking* in this channel that also have issues accidentally pressing `escape` and being sent to the review dashboard?
(esp. curious if it's a :vim: thing, or a general thing)

I just hit a similar (and maybe more annoying version) of this bug in the edit PR description field. I was going to create a code block and on the last ` I entered I accidentally hit `esc` instead and then was already hitting enter to go to the next line of the code box which discarded my changes :melting_face:

i'm curious if allowing *enter* to trigger buttons is useful or dangerous, vs. sticking with web patterns of *spacebar only*

I think for dialogs that are potentially very destructive, more friction (while still being accessible) is better.

in this case, i might say that we shouldn't be autofocusing the destructive button

because even if we went spacebar only, what if you were typing a space, which happens oh idk like every word?!

we should autofocus the dialog box itself

cc <@U02DCQ1C0G6> for design feedback - I can see your point!

that ui element should be an input that you can type into -- sounds like there may be an issue with its styling in firefox which i can look into!

i don't think it's only styling, i tried clicking on it and then typing but nothing happened

it has attribute `disabled`. if i remove it from the element, i can type.

Hi there! I think this issue is fixed - but let us know if it still isn't working!

Screenshare - 2023-07-19 4:39:29 PM.webm

ah i realised you cannot see the on-screen keyboard in the screen capture :sweat_smile:

but yeah clicking doesn't focus anything and typing directly after clicking also doesn't work

Interesting, thanks for the additional screen recording. Creating a ticket for this now!

i just tried on chrome (brave), and can confirm it works, hope that helps

sorry for the delay here! i actually have a fix for this that i was blocked from merging until this morning :slightly_smiling_face: you should see this fixed within an hour or so!

do you see a loading/warning icon after clicking the button?

from our logs, im seeing that we’re encountering issues fetching pull request reviews for your user — could you try updating/verifying your GitHub authentication method via your settings?

do you mind taking a screen recording of what happens when you click the button? im unfortunately not seeing any useful logs that would indicate what is going on here

Hi there! Are you still having issues with this?

We're currently investigating an incident resulting in the website not loading