sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Font collection must have at least one valid typeface.
Labels: platform-ios,engine,platform-mac,a: typography,a: desktop,has reproducible steps,P2,found in release: 2.0,found in release: 2.1,team-engine,triaged-engine

### Problem

```
[VERBOSE-2:FontFamily.cpp(184)] Could not get cmap table size!
[VERBOSE-2:FontCollection.cpp(94)] Font collection must have at least one valid typeface.
```

### Code

```yaml
# pubspec.yaml
flutter:
  # (...)

  fonts:
    - family: Noto Color Emoji
      fonts:
        - asset: assets/fonts/Noto/NotoColorEmoji.ttf

```

Noto Color Emoji is from here: https://noto-website-2.storage.googleapis.com/pkgs/Noto-unhinted.zip

```dart
TextFormField(
  style: TextStyle(fontFamily: 'Noto Color Emoji'),
),
```

### Doctor

```
[✓] Flutter (Channel unknown, 2.0.1, on macOS 11.1 20C69 darwin-arm, locale en-GB)
    • Flutter version 2.0.1 at /Users/albert/fvm/versions/2.0.1
    • Framework revision c5a4b4029c (7 days ago), 2021-03-04 09:47:48 -0800
    • Engine revision 40441def69
    • Dart version 2.12.0

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.4, Build version 12D4e
    • CocoaPods version 1.10.1
```
Repository: flutter
Issue: PopupMenu Overlay should follow target when resizing window
Labels: framework,f: material design,a: quality,platform-web,a: desktop,has reproducible steps,P2,found in release: 3.10,found in release: 3.11,team-design,triaged-design

The overlay generated by clicking the `PopupMenuButton` seems to be positioned relative to the window and hence moves when the window is resized.  

**Expected:** Overlay should follow the target renderbox, in this case the `Container`.

created in DartPad
```
Center(
   child: PopupMenuButton(
          itemBuilder: (context) => ["apple", "orange"]
              .map((e) => PopupMenuItem(
                    child:  Text(e),
                  ))
              .toList(),
          child: Container(
            height: 200,
            width: 300,
            color: Colors.green,
          ),
        ),
    );
```

![ezgif com-video-to-gif](https://user-images.githubusercontent.com/32741490/110799041-c0de9180-8248-11eb-9457-967d967a6783.gif)
Repository: storybook
Issue: dispatched CustomEvent not showing up in Actions
Labels: question / support,addon: actions

**Describe the bug**

Custom made events are not showing up in Actions.  
See [this repository](https://github.com/dersimn/storyboard-customevent-issue) for fully working example: 

`Button.js`
```javascript
import { html } from 'lit-html';

/**
 * Primary UI component for user interaction
 */
export const Button = ({ primary, backgroundColor, size, label }) => {
  function internalOnClickFunction(e) {
    console.log('logged from internalOnClickFunction', e);

    this.dispatchEvent(new Event('foo'));
    this.dispatchEvent(new CustomEvent('bar', {detail: 'foo! bar!'}));
  }

  return html`
    <button
      id="mySelector"
      type="button"
      @click=${internalOnClickFunction}
    >
      ${label}
    </button>
  `;
};
```

`Button.stories.js`
```javascript
import { Button } from './Button';

export default {
  title: 'Example/Button',
  parameters: {
    actions: {
      handles: ['mouseover', 'click', 'foo', 'bar'],
    },
  },
};

const Template = (args) => Button(args);

export const SomeButton = Template.bind({});
SomeButton.args = {
  label: 'SomeButton',
};
```

![screen3](https://user-images.githubusercontent.com/3258452/110801369-775c6980-827d-11eb-97da-a383517f1c34.png)


**To Reproduce**
Steps to reproduce the behavior:

1. `git clone https://github.com/dersimn/storyboard-customevent-issue`
2. Follow instructions in README.md
Repository: material-ui
Issue: Drawer does not transition closed when initialised as open
Labels: bug 🐛,component: drawer

<!--
  Thank you very much for contributing to Material-UI by creating an issue! ❤️
  To avoid duplicate issues we ask you to check off the following list.
-->

<!-- Checked checkbox should look like this: [x] -->

- [x] The issue is present in the latest release.
- [x] I have searched the [issues](https://github.com/mui-org/material-ui/issues) of this repository and believe that this is not a duplicate.

## Current Behavior 😯

Initialising a `Drawer` component in the `open` state, then setting that state to closed, will not perform a close transition for that first state change. Further changes to the `open` state are transitioned properly.

## Expected Behavior 🤔

The `Drawer` should transition each way regardless of what state it was initialised in.

## Steps to Reproduce 🕹

[Codesandbox Demo](https://codesandbox.io/s/materialui-drawer-demo-lxqpx)

Steps:

1. Click on the backdrop to close the `Drawer` from the open state.
2. Observe that it jumps closed instead of transitioning.
3. Observe that the same issue does not occur on further changes, or when initialising in the closed state.

## Context 🔦

I would like the `Drawer` to be initialised as open on certain routes of the React application I am building.

## Your Environment 🌎

````
@material-ui/core: 4.11.3
react: 17.0.1
react-dom: 17.0.1
react-scripts: 4.0.0 
````

Issue is observeable in both Firefox and Chrome on a Windows 10 machine.
Repository: ant-design
Issue: Table with scroll prop doesn't work with x: "100%" and y: 150 set at the same time
Labels: Inactive

- [x] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### Reproduction link
[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/fixed-header-antd4131-forked-h5yzb?file=/index.js)

### Steps to reproduce
Add scroll prop to table component and set the x key to "100%" and the y key to 150. 

### What is expected?
Both a horizontal and vertical scrollbar.

### What is actually happening?
Only a vertical scrollbar will appear.

| Environment | Info |
|---|---|
| antd | 4.13.1 |
| React | 16.14.0 |
| System | Ubuntu 20.04 |
| Browser | Chrome |


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: electron
Issue: [Bug]: Fullscreen is not working on Linux with focusable: false
Labels: platform/linux,bug :beetle:,12-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Electron Version

12

### What operating system are you using?

Ubuntu

### Operating System Version

20.04

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

Fullscreen works.

### Actual Behavior

Fullscreen does not work.

### Testcase Gist URL

https://github.com/hovancik/electron-fullscreen-focusable.git

### Additional Information

Created this from https://github.com/electron/electron/issues/11632 because of your awesome bot.
Repository: TypeScript
Issue: Allow prepending --watch with --clean in CLI --build mode?
Labels: Suggestion,Experience Enhancement

# Suggestion

## 🔍 Search Terms

tsc watch build clean 

## ✅ Viability Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

It would be nice to be able to run `tsc --build --clean --watch` and have the `--clean` operation run before the `--watch` operation. Today we have to run these commands separately.

## 📃 Motivating Example

For developing TypeScript itself, I'll frequently run `tsc -b src/tsc -w` to get `built/local/tsc.js` created. But other commands such as `gulp runtests` seem to clobber over the inputs and/or outputs so I've found I need to first `tsc -b src/tsc --clean` when running them.

## 💻 Use Cases

In general, this would be a nice little shortcut for folks who want to _first_ clean, _then_ watch.
Repository: go
Issue: x/exp/cmd/gorelease: expose analysis.Analyzer
Labels: NeedsInvestigation,FeatureRequest,modules,Tools,Analysis

Frequently I run `gorelease` as part of ci to test if anybody has introduced breaking changes. This works well, but is a separate workflow that I have to run in addition to all the linting that already goes on. It would be nice if I could simply add a phase to my current run of `[]*analysis.Analyzer` and reuse the parsing that is already done.

IIUC, this would require fetching the previous versions' AST as an `analysis.Fact`, so I am neither sure how feasible or efficient this would be, but it would serve to be better integrable into existing metalinters.

EDIT: This may be of less value after #37561, but reparsing the AST does come at cost, so it would be a nice to have regardless.
Repository: go
Issue: runtime: enable random stack relocation 
Labels: NeedsFix,Debugging

It is not allowed to have C pointers into go memory, from my understanding, mostly because the go stack is movable.
The only reliable way to find bugs in this is currently just using manual review.

I propose that there should be a way to force the runtime to move the stack at random intervals.

This could be done entirely in runtime with a ENV variable, or a compile option due to runtime overhead. 

context:
I am currently working on improving performance of a c->go transpiler (ccgo by @cznic, https://gitlab.com/cznic/ccgo) in this case by allowing some pointers to be `*T` instead of `uintptr`. It is a fine line between the 2, but in no circumstance should they ever be mixed because of the movable stack (no C pointer to go stack). ccgo runs all GCC tests to verify it translates properly. Getting all the tests to work isnt too complicated. However there might be cases where a `uintptr` points to go allocated object, and it just works because the stack wasn't moved. It is impossible to verify this doesn't happen, I would have to manually check 1300 GCC test, and preferably also some randomly generated code.
This is of course a unique situation, however I think this could also help less aware people find these problems.

This would of course not be able to verify the code, however, just like fuzzing, it means we can be much more confident in the code.

CC @josharian @ianlancetaylor @prattmic @aclements  on recommendations of josh
Repository: vscode
Issue: Need to be able to specify view type for vscode.notebook.openNotebookDocument
Labels: api,under-discussion,notebook-api

Previously this was supported, but it looks it was [decided to be dropped](https://github.com/microsoft/vscode/issues/93265#issuecomment-795417139).

I was using this functionality in the Live Share extension to get notebook contents from the host when the guest opens a notebook document that the host doesn't yet have open. The notebook should be opened with the content provider that the guest selected (if it's not already open on the host).

In general, there needs to be a programmatic way to open a notebook document, and part of that is specifying the view type. I imagine there are other scenarios where an extension would want to open a notebook behind the scenes and not prompt the user to select a content provider. This isn't possible without being able to specify the view type.
Repository: rust
Issue: Check if expr and value are both needed in rustdoc clean::ConstantKind
Labels: C-cleanup,T-rustdoc

This comes from https://github.com/rust-lang/rust/pull/82873#discussion_r592567123

`value` and `expr` are somewhat similar so we should investigate to check that they're really both needed.
Repository: godot
Issue: GLES3 HTML5 MeshInstance GL_INVALID_OPERATION
Labels: bug,platform:web,topic:rendering,topic:3d

**Godot version:**
3.2.3.stable

**OS/device including version:**
Linux with Nvidia Drivers (460.39)
Chromium 89

**Issue description:**
For every mesh instance added to the scene this gets logged to Chromiums console:
`GL_INVALID_OPERATION: It is undefined behaviour to have a used but unbound uniform buffer.`

**Steps to reproduce:**
1. Create scene
2. Add MeshInstance and camera
3. Click Run in Browser

[Browser GLES3.zip](https://github.com/godotengine/godot/files/6125395/Browser.GLES3.zip)
Repository: terminal
Issue: [MSIX Bucket] Launch issues caused by bad permissions on WindowsApps, and others
Labels: Issue-Bug,Product-Terminal,Needs-Tag-Fix,Issue-Scenario,Culprit-Centennial

There is a class of issues whose root cause _seems_ to be bad permissions on `C:\Program Files\WindowsApps`.

* `wt.exe` can launch the "wrong" copy of Terminal without user settings
   * **DIFFERENTIAL DIAGNOSTIC** The version number switches between (example) `1.7.1991` and `1.7.210451004-release1.7`
* error `0xc0000022` on launch (#9399)

**REPORTERS**: If you have one of these issues, can you share the output of `icacls "C:\Program Files\WindowsApps"` (from an admin shell?)

<details>
<summary>Correct WindowsApps permissions</summary>

```
\Program Files\WindowsApps NT SERVICE\TrustedInstaller:(F)
                           NT SERVICE\TrustedInstaller:(OI)(CI)(IO)(F)
                           S-1-15-3-1024-3635283841-2530182609-996808640-1887759898-3848208603-3313616867-983405619-2501854204:(RX)
                           S-1-15-3-1024-3635283841-2530182609-996808640-1887759898-3848208603-3313616867-983405619-2501854204:(OI)(CI)(IO)(GR,GE)
                           NT AUTHORITY\SYSTEM:(F)
                           NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
                           BUILTIN\Administrators:(CI)(RX)
                           NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(RX)
                           NT AUTHORITY\NETWORK SERVICE:(OI)(CI)(RX)
                           NT AUTHORITY\RESTRICTED:(OI)(CI)(RX)
                           BUILTIN\Users:(Rc,S,RD,REA,X,RA)
```

</details>


----

zadjii-msft notes circa 2023-09-06:

There's a collection of "crash on startup" issues which started around 1.16. They're all in the neighborhood of `Cannot_create_instance_of_type__Microsoft.UI.Xaml.Controls.XamlControlsResources` or `winrt::impl::consume_Windows_ApplicationModel_IPackageStatics_winrt::Windows::ApplicationModel::IPackageStatics_::Current`, depending on how the exception was handled. More notes in: 

* https://github.com/microsoft/terminal/issues/15583#issuecomment-1708760392 (collected notes, resolution steps)
* https://github.com/microsoft/terminal/issues/15583#issuecomment-1708641554 (x-links a bunch of bugs)
* https://github.com/microsoft/terminal/issues/15526#issuecomment-1708635865 (another couple dupes)
* https://github.com/microsoft/terminal/issues/14961#issuecomment-1461141118 (an early analysis)
Repository: go
Issue: cmd/go/internal/doc: exit status printed
Labels: NeedsFix

### What version of Go are you using (`go version`)?
<pre>
[user@localhost ~]$ go version
go version go1.16 linux/amd64
</pre>
### Does this issue reproduce with the latest release?
yes
### What operating system and processor architecture are you using (`go env`)?
<details><summary><code>go env</code> Output</summary><br><pre>
[user@localhost ~]$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/user/.cache/go-build"
GOENV="/home/user/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY="*.sc-corp.net"
GONOSUMDB="*.sc-corp.net"
GOOS="linux"
GOPATH="/home/user/go"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/user/.local/share/umake/go/go-lang"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/user/.local/share/umake/go/go-lang/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/tmp/test/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build698062687=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?
Create the following `go.mod` file:
```go
module test
  
go 1.16

require k8s.io/client-go v12.0.0+incompatible
```
Create the following `main.go` file:
```go
package main
  
import (
        "fmt"

        "k8s.io/client-go/pkg/version"
)

func main() { fmt.Println(version.Get()) }
```
### What did you expect to see?
```
[user@localhost test]$ go doc k8s.io/client-go/pkg/version
go: k8s.io/client-go@v12.0.0+incompatible: missing go.sum entry; to add it:
        go mod download k8s.io/client-go
go: k8s.io/client-go@v12.0.0+incompatible: missing go.sum entry; to add it:
        go mod download k8s.io/client-go
doc: go/build: go list k8s.io/client-go/pkg/version: exit status 1
go: k8s.io/client-go@v12.0.0+incompatible: missing go.sum entry; to add it:
        go mod download k8s.io/client-go
```
### What did you see instead?
The toolchain is adding an extra newline and warning me about the exit status:
```
[user@localhost test]$ go doc k8s.io/client-go/pkg/version
go: k8s.io/client-go@v12.0.0+incompatible: missing go.sum entry; to add it:
        go mod download k8s.io/client-go
go: k8s.io/client-go@v12.0.0+incompatible: missing go.sum entry; to add it:
        go mod download k8s.io/client-go
doc: go/build: go list k8s.io/client-go/pkg/version: exit status 1
go: k8s.io/client-go@v12.0.0+incompatible: missing go.sum entry; to add it:
        go mod download k8s.io/client-go

exit status 1
```
Repository: electron
Issue: [Feature Request]: shell.openExternal should return error message
Labels: enhancement :sparkles:,12-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

While `shell.openPath` return an error message when it fails, the `shell.openExternal` always returns `undefined`. Use case is to have an error for not registered URL schemes, like `shell.openExternal('sms:123456')`.

### Proposed Solution

Do return `string` error from `shell.openExternal` if the scheme opening fails.

### Additional Information

Some platforms, like Windows, offers to install app for unknown schemes - it's perfect behaviour (the user has a feedback) - and it  means `shell.openExternal` does not fail. While other platforms, like Linux just does nothing. `shell.openExternal` on Linux use `xdg-open` and `xdg-open` fails for unknown URI schemes, so Electron `shell.openExternal` should fails, too (like `shell.openPath`).

Current Electron is v12.0
Repository: create-react-app
Issue: Proxying requests still getting blocked by CORS
Labels: needs triage,issue: bug report

### Describe the bug

- CRA is being served on `http://localhost:3000`
- In `package.json` I have this line: `"proxy":  "http://localhost:8000"`
- My backend is uvicorn serving a FastAPI application
- Making the request (`GET http://localhost:8000/api/features`) with Postman is successful
- The request in React (using axios) is blocked

<img width="1070" alt="Screen Shot 2021-03-11 at 2 54 57 PM" src="https://user-images.githubusercontent.com/69015187/110853871-c0aaba00-8279-11eb-9dd7-49d20a076c8d.png">
<img width="832" alt="Screen Shot 2021-03-11 at 3 02 46 PM" src="https://user-images.githubusercontent.com/69015187/110854622-da003600-827a-11eb-98d7-23b00c5f0f8a.png">

### Did you try recovering your dependencies?

Yes: updated npm, deleted node_modules and package-lock, reinstalled

### Which terms did you search for in User Guide?

- Proxy
- CORS

### Environment

Environment Info:

  current version of create-react-app: 4.0.3

  System:
    OS: macOS
  Binaries:
    Node: 13.11.0 - ~/.nvm/versions/node/v13.11.0/bin/node
    Yarn: Not Found
    npm: 7.6.2 - ~/.nvm/versions/node/v13.11.0/bin/npm
  Browsers:
    Chrome: 89.0.4389.82
    Firefox: 86.0
  npmPackages:
    react: ^17.0.1 => 17.0.1 
    react-dom: ^17.0.1 => 17.0.1 
    react-scripts: 4.0.3 => 4.0.3 
  npmGlobalPackages:
    create-react-app: Not Found

### Steps to reproduce

1. Have a local uvicorn/FastAPI backend running on `http://localhost:8000`
2. Add `"proxy": "http://localhost:8000"` to your package.json
3. Start your local CRA app running on `http://localhost:3000`
4. Make a request from CRA to your backend
5. Note the error messages

### Expected behavior

The proxy usually works fine for me, I don't understand why it's not working in this new project. It seems the browser is receiving the response as expected, but it's still getting blocked despite the proxy.

### Actual behavior

The request seems to be getting blocked by CORS in both Chrome and FF

<img width="1070" alt="Screen Shot 2021-03-11 at 2 54 57 PM" src="https://user-images.githubusercontent.com/69015187/110853871-c0aaba00-8279-11eb-9dd7-49d20a076c8d.png">
<img width="832" alt="Screen Shot 2021-03-11 at 3 02 46 PM" src="https://user-images.githubusercontent.com/69015187/110854622-da003600-827a-11eb-98d7-23b00c5f0f8a.png">

### Reproducible demo

I don't know how to reproduce this exact set of circumstances. The proxy normally works fine for me. Hopefully someone can give feedback based on the response screenshots I shared.
Repository: TypeScript
Issue: Misleading error message for duplicate CLI flags
Labels: Suggestion,Experience Enhancement

# Bug Report

### 🔎 Search Terms

tsc multiple flag options cli

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about CLI option parsing

### ⏯ Playground Link

N/A

### 💻 Code

Any of:

```ts
tsc -b -b
tsc -b --build
tsc -b --clean --build
```

### 🙁 Actual behavior

```
tsc -b -b      
error TS5072: Unknown build option '-b'.
```

### 🙂 Expected behavior

Something indicating the flag was provided twice, not that it's unknown?

```
tsc -b -b      
error TS5072: Duplicate build option '-b' provided.
```