ernie-research/MEnvBench huggingface dataset:
Repository: dequelabs/axe-core (JavaScript)

Issue:
axe-core's selectors incorrectly handle the `xmlns` attribute
### Product

axe-core

### Product Version

4.8.1

### Latest Version

- [X] I have tested the issue with the latest version of the product

### Issue Description

#### Expectation
The selector produced by axe-core should match an element on the page.

#### Actual
The selector produced by axe-core does not match an element on the page. This manifests itself in the axe DevTools Extension as being unable to highlight or inspect an element.

#### How to Reproduce
The underlying problem can be reproduced using this code snippet:

```html
<html>

<body>
  <svg xmlns="http://www.w3.org/2000/svg">
    <circle cx="50" cy="50" r="40" stroke="black" stroke-width="3" fill="red" />
  </svg>
  <svg xmlns="http://www.w3.org/1999/svg">
    <circle cx="50" cy="50" r="40" stroke="black" stroke-width="3" fill="red" />
  </svg>
</body>

</html>
```

Using axe-core's utilities to generate a selector results in an unusable selector:
```
const tree = axe.utils.getFlattenedTree(document)
> undefined
axe._selectorData = axe.commons.utils.getSelectorData(tree)
> {classes: {…}, tags: {…}, attributes: {…}}
axe.commons.utils.getSelector(document.querySelectorAll('circle')[0])
> ':root > circle'
```

#### Additional context
I've dug into axe-core, and it looks like the reason why this happens is because similar.length === 0 [here](https://github.com/dequelabs/axe-core/blob/f3569c53d6ad7964fc2928c869d0d60df2864eed/lib/core/utils/get-selector.js#L387). The reason why the list of similar is empty is because the clippath element does not "[match](https://github.com/dequelabs/axe-core/blob/f3569c53d6ad7964fc2928c869d0d60df2864eed/lib/core/utils/get-selector.js#L381)" the selector svg[viewBox="0 0 80 80"][fill="none"][xmlns="http://www.w3.org/2000/svg"] > defs > clippath , even though it "should". The problem is with the xmlns attribute selector. If you remove it, the selector works. You can even play around with it with the code snippet I'll post in the thread and using document.querySelectorAll--the browser does not like the xmlns attribute. I was about to post an issue in Chromium, but tried it out in other browsers and realized they all have the same issue. After further digging, it seems that not supporting namespaces is just [part of the spec](https://dom.spec.whatwg.org/#selectors).

A possible solution is to add `xmlns` to the list of ignored attributes: https://github.com/dequelabs/axe-core/blob/f3569c53d6ad7964fc2928c869d0d60df2864eed/lib/core/utils/get-selector.js#L8




Fix (patch):
diff --git a/lib/core/utils/get-selector.js b/lib/core/utils/get-selector.js
index 3ac8aeab99..470946705b 100644
--- a/lib/core/utils/get-selector.js
+++ b/lib/core/utils/get-selector.js
@@ -22,7 +22,8 @@ const ignoredAttributes = [
   'aria-expanded',
   'aria-grabbed',
   'aria-pressed',
-  'aria-valuenow'
+  'aria-valuenow',
+  'xmlns'
 ];
 const MAXATTRIBUTELENGTH = 31;
 const attrCharsRegex = /([\\"])/g;
Repository: dequelabs/axe-core (JavaScript)

Issue:
target-size: false positive for small targets in focusable tabpanels
### Product

axe-core

### Product Version

4.10.2

### Latest Version

- [x] I have tested the issue with the latest version of the product

### Issue Description

A common pattern with tab panels is for the panel to be focusable, but not clickable. The tab panel in this case isn't a "target" for the purposes of 2.5.5/2.5.8 because it doesn't respond to pointer events. However, because axe-core currently considers `tabpanel` to be a `widget` role type, the `target-offset` check considers a focusable tabpanel to be a target.

I think the fix for this is likely to update `aria-roles.js` to treat `tabpanel` as a `structure` role rather than a `widget` role. The ARIA spec is ambiguous about which is correct ([wai-aria-1.2 §5.3.2 Widget Roles](https://www.w3.org/TR/wai-aria-1.2/#widget_roles) says that tabpanel is a widget, but the [tabpanel role section](https://www.w3.org/TR/wai-aria-1.2/#tabpanel) says it rolls up to section/structure), but I think in practice structure is more accurate and would fix the false positive here.

#### Expectation
When an interactive target is contained in a focusable `tabpanel`, it shouldn't cause `target-offset` violations.

#### Actual
Axe reports a violation.

#### How to Reproduce
```html
<div role="tabpanel" tabindex="0">
  <h2>My cool tabpanel content</h2>
  <input id="target" type="checkbox">A checkbox inside the focusable tabpanel</input>
</div>
```

```js
await axe.run('#target', { runOnly: 'target-size' })
```

#### Additional context
I think we meant to address this in #4371 / #4421, but missed it due to the ambiguity in the ARIA spec mentioned above.



Fix (patch):
diff --git a/lib/checks/aria/valid-scrollable-semantics-evaluate.js b/lib/checks/aria/valid-scrollable-semantics-evaluate.js
index 0241f6cf83..946f290471 100644
--- a/lib/checks/aria/valid-scrollable-semantics-evaluate.js
+++ b/lib/checks/aria/valid-scrollable-semantics-evaluate.js
@@ -30,7 +30,8 @@ const VALID_ROLES_FOR_SCROLLABLE_REGIONS = {
   navigation: true,
   region: true,
   search: false,
-  status: true
+  status: true,
+  tabpanel: true
 };
 
 /**
diff --git a/lib/standards/aria-roles.js b/lib/standards/aria-roles.js
index 7a6d325773..cd49dc37a8 100644
--- a/lib/standards/aria-roles.js
+++ b/lib/standards/aria-roles.js
@@ -781,7 +781,10 @@ const ariaRoles = {
     superclassRole: ['composite']
   },
   tabpanel: {
-    type: 'widget',
+    // Spec ambiguity: Aria 1.1 and 1.2 both say that tabpanel rolls up to
+    // structure via its section superclass, but also include it as a widget
+    // in §5.3.2 Widget Roles.
+    type: 'structure',
     // Spec difference: Aria-expanded removed in 1.2
     allowedAttrs: ['aria-expanded'],
     superclassRole: ['section'],
Repository: dequelabs/axe-core (JavaScript)

Issue:
Should role=slider allow aria-valuetext as an alternative to aria-valuenow?
According to WAI-ARIA, aria-valuenow is required for role=slider, even if it has aria-valuetext. From NVDA, JAWS and VO testing it looks like aria-valuetext works well as an alternative. While slider is intended as a value input mechanic, it is often used in video players. Their time value is better expressed with text than it is with a number. Having a number there at all may be more confusing than helpful. 




Fix (patch):
diff --git a/lib/checks/aria/aria-required-attr-evaluate.js b/lib/checks/aria/aria-required-attr-evaluate.js
index f10642c4c4..f623ba4be7 100644
--- a/lib/checks/aria/aria-required-attr-evaluate.js
+++ b/lib/checks/aria/aria-required-attr-evaluate.js
@@ -54,6 +54,11 @@ export default function ariaRequiredAttrEvaluate(
   ) {
     return true;
   }
+  // Non-normative exception for things like media player seek slider.
+  // Tested to work in various screen readers.
+  if (role === 'slider' && virtualNode.attr('aria-valuetext')?.trim()) {
+    return true;
+  }
 
   const elmSpec = getElementSpec(virtualNode);
   const missingAttrs = requiredAttrs.filter(
Repository: parse-community/Parse-SDK-JS (JavaScript)

Issue:
Add `installationId` option to `Parse.Cloud.run`
### New Feature / Enhancement Checklist
<!--
    Check every following box [x] before submitting your issue.
    Click the "Preview" tab for better readability.
    Thanks for contributing to Parse Platform!
-->

- [x] I am not disclosing a [vulnerability](https://github.com/parse-community/parse-server/blob/master/SECURITY.md).
- [x] I am not just asking a [question](https://github.com/parse-community/.github/blob/master/SUPPORT.md).
- [x] I have searched through [existing issues](https://github.com/parse-community/Parse-SDK-JS/issues?q=is%3Aissue).

### Current Limitation

`Parse.Cloud.run` does not allow take the `installationId` option to execute a Cloud Function from a specific installation.

### Feature / Enhancement Description

Add `installationId` option to method options.

### Example Use Case

```
await Parse.Cloud.run('aFunction', null, { sessionToken, installationId });
```

### Alternatives / Workarounds

Manually set the global `installationId`:

```
Parse.CoreManager.getInstallationController()._setInstallationIdCache('abc');
```



Discussion: 
### Thanks for opening this issue!

- 🎉 We are excited about your ideas for improvement!

<!-- parse-issue-bot-meta-tag-id {"suggestPr":false,"thanksFeature":true,"thanksPr":false} -->


🎉 This change has been released in version [4.2.0-alpha.3](https://github.com/parse-community/Parse-SDK-JS/releases/tag/4.2.0-alpha.3)



Fix (patch):
diff --git a/package-lock.json b/package-lock.json
index 00e883d1a..0548f1250 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -45402,7 +45402,7 @@
       "version": "git+ssh://git@github.com/parse-community/parse-server.git#c78a5a6f10ce09032579fed8ef4cbd84c1ee96a9",
       "integrity": "sha512-C6E8mkVW5IUtliqfH+StD0K6ycJJH7GVbmwj0zou9crKfKNP4iiLwBGklnMM9yBmfKpj2fMGztXFDju5HZ3irw==",
       "dev": true,
-      "from": "parse-server@git+https://github.com/parse-community/parse-server#c78a5a6f10ce09032579fed8ef4cbd84c1ee96a9",
+      "from": "parse-server@git+https://github.com/parse-community/parse-server#alpha",
       "requires": {
         "@babel/eslint-parser": "7.19.1",
         "@graphql-tools/merge": "8.3.6",
diff --git a/src/Cloud.js b/src/Cloud.js
index c42a0ba95..4bf748d3a 100644
--- a/src/Cloud.js
+++ b/src/Cloud.js
@@ -47,6 +47,9 @@ export function run(name: string, data: mixed, options: RequestOptions): Promise
   if (options.sessionToken) {
     requestOptions.sessionToken = options.sessionToken;
   }
+  if (options.installationId) {
+    requestOptions.installationId = options.installationId;
+  }
   if (options.context && typeof options.context === 'object') {
     requestOptions.context = options.context;
   }
Repository: npm/node-semver (JavaScript)

Issue:
[BUG] inc() may produce invalid semver with ReleaseType: prerelease
# What / Why
Given an identifier I want to increment a prerelease version.

### Current Behavior
Given an 'invalid' identifier, `inc()` will produce an invalid `semver`.

### Steps to Reproduce
```
const identifier = 'hotfix/410';
const incremented = inc(parse('0.0.1'), 'prerelease', identifier);
console.log(!!valid(incremented));
// => false
```
### Expected Behavior
The documentation of `inc()` specifies this:
```
Return the version incremented by the release type (major, premajor, minor, preminor, patch, prepatch, or prerelease), or null if it's not valid
```
In the case above `inc()` is not returning null, even though the resulting version is not a valid `semver.` Either the documentation needs to be changed to 'or null if the ReleaseType is not valid' or `inc()` needs to check the validity of the `semver` before returning it.



Fix (patch):
diff --git a/classes/semver.js b/classes/semver.js
index 13e66ce4..12832462 100644
--- a/classes/semver.js
+++ b/classes/semver.js
@@ -10,7 +10,7 @@ class SemVer {
 
     if (version instanceof SemVer) {
       if (version.loose === !!options.loose &&
-          version.includePrerelease === !!options.includePrerelease) {
+        version.includePrerelease === !!options.includePrerelease) {
         return version
       } else {
         version = version.version
@@ -176,6 +176,19 @@ class SemVer {
   // preminor will bump the version up to the next minor release, and immediately
   // down to pre-release. premajor and prepatch work the same way.
   inc (release, identifier, identifierBase) {
+    if (release.startsWith('pre')) {
+      if (!identifier && identifierBase === false) {
+        throw new Error('invalid increment argument: identifier is empty')
+      }
+      // Avoid an invalid semver results
+      if (identifier) {
+        const match = `-${identifier}`.match(this.options.loose ? re[t.PRERELEASELOOSE] : re[t.PRERELEASE])
+        if (!match || match[1] !== identifier) {
+          throw new Error(`invalid identifier: ${identifier}`)
+        }
+      }
+    }
+
     switch (release) {
       case 'premajor':
         this.prerelease.length = 0
@@ -249,10 +262,6 @@ class SemVer {
       case 'pre': {
         const base = Number(identifierBase) ? 1 : 0
 
-        if (!identifier && identifierBase === false) {
-          throw new Error('invalid increment argument: identifier is empty')
-        }
-
         if (this.prerelease.length === 0) {
           this.prerelease = [base]
         } else {
Repository: npm/node-semver (JavaScript)

Issue:
[BUG] semver.satisfied false positive
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current Behavior

From: https://github.com/npm/npm-pick-manifest/pull/87#pullrequestreview-1514076507

> This now returns true: semver.satisfies('2.0.0', '== 1.0.0 || foo', { loose: true })) whereas it did not previously

### Expected Behavior

Should return false

### Steps To Reproduce

_No response_

### Environment

_No response_



Fix (patch):
diff --git a/classes/range.js b/classes/range.js
index a7d37203..7e7c4141 100644
--- a/classes/range.js
+++ b/classes/range.js
@@ -38,7 +38,7 @@ class Range {
     this.set = this.raw
       .split('||')
       // map the range to a 2d array of comparators
-      .map(r => this.parseRange(r))
+      .map(r => this.parseRange(r.trim()))
       // throw out any comparator lists that are empty
       // this generally means that it was not a valid range, which is allowed
       // in loose mode, but will still throw if the WHOLE range is invalid.
Repository: processing/p5.js (JavaScript)

Issue:
blendMode not working when doing point() drawing in webgl
### Most appropriate sub-area of p5.js?

- [ ] Accessibility
- [X] Color
- [ ] Core/Environment/Rendering
- [ ] Data
- [ ] DOM
- [ ] Events
- [ ] Image
- [ ] IO
- [ ] Math
- [ ] Typography
- [ ] Utilities
- [X] WebGL
- [ ] Build Process
- [ ] Unit Testing
- [ ] Internalization
- [ ] Friendly Errors
- [ ] Other (specify if possible)

### p5.js version

1.6.0

### Web browser and version

Chrome

### Operating System

Windows11

### Steps to reproduce this

### Steps:
1. Specify ADD blend using blendMode()
2. Draw a red point and a blue point so that they overlap using point()
3. The color of the overlapping part becomes the color of the point drawn later

### Snippet:

```js
function setup(){
  createCanvas(400,400,WEBGL);
  background(0);
  blendMode(ADD);
  strokeWeight(100);

  stroke(255,0,0);
  point(0,0,0);
  stroke(0,0,255);
  point(50,0,0);
}
```
Drawing result:
![pointBug2](https://user-images.githubusercontent.com/39549290/224692482-4f21d9f9-f473-4312-a79b-844ebfdc75af.png)

Expected result:
![pointBug](https://user-images.githubusercontent.com/39549290/224692573-a7465678-65ed-4264-ac33-d898b2cf784e.png)

### Suggestion for solution
It is probably because _applyColorBlend() is not executed in _drawPoints(), so I think that this one line should be added.

```javascript
_main.default.RendererGL.prototype._drawPoints = function (vertices, vertexBuffer) {
  var gl = this.GL;
  var pointShader = this._getImmediatePointShader();
  this._setPointUniforms(pointShader);
  this._bindBuffer(vertexBuffer, gl.ARRAY_BUFFER, this._vToNArray(vertices), Float32Array, gl.STATIC_DRAW);
  pointShader.enableAttrib(pointShader.attributes.aPosition, 3);

  this._applyColorBlend(this.curStrokeColor); // I think adding this line will fix the bug.

  gl.drawArrays(gl.Points, 0, vertices.length);
  pointShader.unbindShader();
};
```



Fix (patch):
diff --git a/src/webgl/p5.RendererGL.Retained.js b/src/webgl/p5.RendererGL.Retained.js
index a024f0d67f..e32ad93d41 100644
--- a/src/webgl/p5.RendererGL.Retained.js
+++ b/src/webgl/p5.RendererGL.Retained.js
@@ -238,6 +238,8 @@ p5.RendererGL.prototype._drawPoints = function(vertices, vertexBuffer) {
 
   pointShader.enableAttrib(pointShader.attributes.aPosition, 3);
 
+  this._applyColorBlend(this.curStrokeColor);
+
   gl.drawArrays(gl.Points, 0, vertices.length);
 
   pointShader.unbindShader();
Repository: processing/p5.js (JavaScript)

Issue:
beginClip() is accidentally being applied to framebuffers
### Most appropriate sub-area of p5.js?
- [x] WebGL

### p5.js version

1.9.1

### Web browser and version

Chrome 124 (not Firefox, weirdly!)

### Operating system

MacOS 14.2.1

### Steps to reproduce this

### Steps:
1. Start clipping to a shape
2. Draw something to a framebuffer. The clip shouldn't be applied to the framebuffer's context.
3. Stop clipping
4. Draw the framebuffer to the main canvas
5. The framebuffer should appear unclipped, since its framebuffer context was never clipped, and clipping was not applied when drawing it to the main canvas.

### Snippet:

```js
let fbo

function setup() {
  createCanvas(400, 400, WEBGL);
  fbo = createFramebuffer()
}

function draw() {
  background(220);
  push()
  beginClip()
  circle(0, 0, 200)
  endClip()
    
  fbo.draw(() => {
    console.log(drawingContext.isEnabled(drawingContext.STENCIL_TEST))
    fill('red')
    noStroke()
    plane(width, height)
  })
  pop()
  
  imageMode(CENTER)
  image(fbo, 0, 0)
  
  noLoop()
}
```

The expected output is a full red canvas, but instead we get an empty canvas.



Fix (patch):
diff --git a/src/webgl/p5.Framebuffer.js b/src/webgl/p5.Framebuffer.js
index 28b0c6ec61..1347bed038 100644
--- a/src/webgl/p5.Framebuffer.js
+++ b/src/webgl/p5.Framebuffer.js
@@ -849,6 +849,7 @@ class Framebuffer {
     this.target._renderer.uMVMatrix.set(
       this.target._renderer._curCamera.cameraMatrix
     );
+    this.target._renderer._applyStencilTestIfClipping();
   }
 
   /**
Repository: sindresorhus/execa (JavaScript)

Issue:
Wait for streams completion on errors
When passing a `{ file }`, `Writable` or `WritableStream` to the `stdout`/`stderr` option, and the process is terminated (e.g. due to a `timeout`), those streams are destroyed. However, we currently do not wait for their destruction before resolving the Execa promise. We should do so.



Fix (patch):
diff --git a/lib/stream.js b/lib/stream.js
index 153acff003..6192917fb7 100644
--- a/lib/stream.js
+++ b/lib/stream.js
@@ -118,6 +118,7 @@ export const getSpawnedResult = async ({
 
 	const stdioPromises = spawned.stdio.map((stream, index) => getStdioPromise({stream, stdioStreams: stdioStreamsGroups[index], encoding, buffer, maxBuffer}));
 	const allPromise = getAllPromise({spawned, encoding, buffer, maxBuffer});
+	const customStreamsEndPromises = waitForCustomStreamsEnd(customStreams);
 
 	try {
 		return await Promise.race([
@@ -125,7 +126,7 @@ export const getSpawnedResult = async ({
 				once(spawned, 'exit'),
 				Promise.all(stdioPromises),
 				allPromise,
-				...waitForCustomStreamsEnd(customStreams),
+				...customStreamsEndPromises,
 			]),
 			...throwOnCustomStreamsError(customStreams),
 			...throwIfStreamError(spawned.stdin),
@@ -139,6 +140,7 @@ export const getSpawnedResult = async ({
 			getBufferedData(allPromise, encoding),
 		]);
 		cleanupStdioStreams(customStreams, error);
+		await Promise.allSettled(customStreamsEndPromises);
 		return results;
 	} finally {
 		controller.abort();
Repository: sindresorhus/execa (JavaScript)

Issue:
Improve validation of process arguments
We currently validate that the file passed as argument is a string, the arguments is an array and the options is a plain object.

We should also validate that the arguments are not objects. Allowing non-string primitive types might be ok since that's pretty common to pass those as arguments (especially numbers), even though they are converted to strings under-the-hood. But passing objects is almost always not intentional.



Fix (patch):
diff --git a/lib/arguments/escape.js b/lib/arguments/escape.js
index 22afd7104b..2bb3ad6522 100644
--- a/lib/arguments/escape.js
+++ b/lib/arguments/escape.js
@@ -7,9 +7,7 @@ export const joinCommand = (filePath, rawArgs) => {
 	return {command, escapedCommand};
 };
 
-const escapeControlCharacters = arg => typeof arg === 'string'
-	? arg.replaceAll(SPECIAL_CHAR_REGEXP, character => escapeControlCharacter(character))
-	: String(arg);
+const escapeControlCharacters = arg => arg.replaceAll(SPECIAL_CHAR_REGEXP, character => escapeControlCharacter(character));
 
 const escapeControlCharacter = character => {
 	const commonEscape = COMMON_ESCAPES[character];
diff --git a/lib/arguments/options.js b/lib/arguments/options.js
index 9d5a06ff46..feb1e4b7c5 100644
--- a/lib/arguments/options.js
+++ b/lib/arguments/options.js
@@ -20,11 +20,21 @@ export const normalizeArguments = (rawFile, rawArgs = [], rawOptions = {}) => {
 		throw new TypeError(`Second argument must be either an array of arguments or an options object: ${args}`);
 	}
 
+	if (args.some(arg => typeof arg === 'object' && arg !== null)) {
+		throw new TypeError(`Second argument must be an array of strings: ${args}`);
+	}
+
+	const normalizedArgs = args.map(String);
+	const nullByteArg = normalizedArgs.find(arg => arg.includes('\0'));
+	if (nullByteArg !== undefined) {
+		throw new TypeError(`Arguments cannot contain null bytes ("\\0"): ${nullByteArg}`);
+	}
+
 	if (!isPlainObject(options)) {
 		throw new TypeError(`Last argument must be an options object: ${options}`);
 	}
 
-	return [filePath, args, options];
+	return [filePath, normalizedArgs, options];
 };
 
 export const handleArguments = (filePath, rawArgs, rawOptions) => {
Repository: style-dictionary/style-dictionary (JavaScript)

Issue:
Error message that suggests setting log.verbosity to verbose should link to docs
Would be nice if the error message about setting the log.verbosity to verbose gave a link to the Logging section in the docs so the user can see how exactly to do this, as this isn't always immediately clear to users just from the error message.



Fix (patch):
diff --git a/.changeset/seven-dolphins-dream.md b/.changeset/seven-dolphins-dream.md
new file mode 100644
index 000000000..e20be5587
--- /dev/null
+++ b/.changeset/seven-dolphins-dream.md
@@ -0,0 +1,5 @@
+---
+'style-dictionary': patch
+---
+
+Added link to logging documentation inside all of the warnings and errors that refer to verbosity.
diff --git a/lib/utils/groupMessages.js b/lib/utils/groupMessages.js
index 1ad8069f3..8afb2919b 100644
--- a/lib/utils/groupMessages.js
+++ b/lib/utils/groupMessages.js
@@ -11,7 +11,7 @@
  * and limitations under the License.
  */
 
-export const verbosityInfo = `Use log.verbosity "verbose" or use CLI option --verbose for more details.`;
+export const verbosityInfo = `Use log.verbosity "verbose" or use CLI option --verbose for more details.\nRefer to: https://styledictionary.com/reference/logging/`;
 
 export class GroupMessages {
   constructor() {