Viewer nodes affecting exposed parameters in a menu/index switch system. #50

New Issue

Triager-bot · 2026-04-12T17:47:03Z

Triager-bot commented

2026-04-12 17:47:03 +00:00

Original bug report: https://projects.blender.org/blender/blender/issues/157229

System Information
Operating system: WINDOWS 11
Graphics card: NVIDIA Geforce RTX 4090 Laptop GPU

Blender Version
Broken: 5.1.0
Worked: 5.0.1

Problem
I am no dev expert, nor coding savvy so bear with me :) I am here following a convo on chat.blender where I was suggested to submit a bug report.
I am noticing that Viewer nodes, either active or inactive, are affecting exposed parameters regardless of what menu option driving index switches towards the end of my nodes is chosen.

Exact steps for others to reproduce the error
Attached is a blend with one of my nodes. Bottom left is the node. Bottom right in a red frame the viewer node that is affecting the exposed paramaters regardless of whether it is active or not. Delete it in 5.0.1 and then in 5.1.0 and you will see what i mean.

Feature or bug?

Many many thanks in advanced.

Original bug report: https://projects.blender.org/blender/blender/issues/157229 **System Information** Operating system: WINDOWS 11 Graphics card: NVIDIA Geforce RTX 4090 Laptop GPU **Blender Version** Broken: 5.1.0 Worked: 5.0.1 **Problem** I am no dev expert, nor coding savvy so bear with me :) I am here following a convo on chat.blender where I was suggested to submit a bug report. I am noticing that Viewer nodes, either active or inactive, are affecting exposed parameters regardless of what menu option driving index switches towards the end of my nodes is chosen. **Exact steps for others to reproduce the error** Attached is a blend with one of my nodes. Bottom left is the node. Bottom right in a red frame the viewer node that is affecting the exposed paramaters regardless of whether it is active or not. Delete it in 5.0.1 and then in 5.1.0 and you will see what i mean. Feature or bug? Many many thanks in advanced.

Triager-bot added the

Status

Needs review

label 2026-04-12 17:47:03 +00:00

Triager-bot commented

2026-04-12 17:47:25 +00:00

Report is clear

LLM Reasoning

Got it, let's analyze this bug report. The user is asking if the bug report clearly describes the issue. First, check the clarity of the problem description and steps to reproduce.

The title mentions "Viewer nodes affecting exposed parameters in a menu/index switch system." The body explains that viewer nodes (active or inactive) affect exposed parameters regardless of the menu option chosen for index switches. The steps say to use an attached blend file: delete the viewer node in 5.0.1 and 5.1.0 to see the difference.

Wait, but does the report clearly state the issue? Let's see: the problem is that viewer nodes (even inactive) affect exposed parameters when using a menu/index switch system. The steps are there, though they rely on an attached file. But the question is about clarity of text description and steps. The user explains what's happening (viewer nodes affecting params regardless of activity or menu choice). The steps tell others to delete the viewer node in different versions.

Is it clear? Let's check: the problem statement says "Viewer nodes, either active or inactive, are affecting exposed parameters regardless of what menu option driving index switches towards the end of my nodes is chosen." That's a clear description. The steps mention deleting the viewer node in 5.0.1 and 5.1.0 to reproduce.

So yes, it clearly describes the issue. Wait, but wait: does the report have enough info? The user says "Attached is a blend with one of my nodes" – so the steps rely on an attached file, but the text description is clear. The question is about clarity of text and steps (if present). So even if there's an attachment, the text part is clear.

So the answer should be Yes? Wait, let me recheck. The user's problem: viewer nodes affecting exposed parameters regardless of activity or menu choice. Steps: delete viewer node in 5.0.1 and 5.1.0 to see. That's clear enough for a bug report. So yes.

JSON Data

{
"llm_judgement": true,
"processing_time": 21.602480000000003
}

### Report is clear <details> <summary>LLM Reasoning</summary> Got it, let's analyze this bug report. The user is asking if the bug report clearly describes the issue. First, check the clarity of the problem description and steps to reproduce. The title mentions "Viewer nodes affecting exposed parameters in a menu/index switch system." The body explains that viewer nodes (active or inactive) affect exposed parameters regardless of the menu option chosen for index switches. The steps say to use an attached blend file: delete the viewer node in 5.0.1 and 5.1.0 to see the difference. Wait, but does the report clearly state the issue? Let's see: the problem is that viewer nodes (even inactive) affect exposed parameters when using a menu/index switch system. The steps are there, though they rely on an attached file. But the question is about clarity of text description and steps. The user explains what's happening (viewer nodes affecting params regardless of activity or menu choice). The steps tell others to delete the viewer node in different versions. Is it clear? Let's check: the problem statement says "Viewer nodes, either active or inactive, are affecting exposed parameters regardless of what menu option driving index switches towards the end of my nodes is chosen." That's a clear description. The steps mention deleting the viewer node in 5.0.1 and 5.1.0 to reproduce. So yes, it clearly describes the issue. Wait, but wait: does the report have enough info? The user says "Attached is a blend with one of my nodes" – so the steps rely on an attached file, but the text description is clear. The question is about clarity of text and steps (if present). So even if there's an attachment, the text part is clear. So the answer should be Yes? Wait, let me recheck. The user's problem: viewer nodes affecting exposed parameters regardless of activity or menu choice. Steps: delete viewer node in 5.0.1 and 5.1.0 to see. That's clear enough for a bug report. So yes. </details> <details> <summary>JSON Data</summary> { "llm_judgement": true, "processing_time": 21.602480000000003 } </details>

👍 1

Triager-bot commented

2026-04-12 17:48:00 +00:00

Report is specific

LLM Reasoning

Got it, let's figure this out. The question is asking if the bug report is specific or generic. First, let's recall the definitions: specific is about a particular issue (like crashing with a specific feature), generic is vague (like just crashing while rendering).

Looking at the bug report: The title mentions "Viewer nodes affecting exposed parameters in a menu/index switch system." The problem describes that viewer nodes are affecting exposed parameters regardless of being active or not, and there's an exact reproduction step (delete the viewer node in different Blender versions). So it's about a specific issue with viewer nodes in a particular setup (menu/index switch system), not a vague "crashing while rendering" type.

Wait, but let's check again. The example for generic is "Crashing while rendering" which is vague. This report has a specific scenario: menu/index switch system, viewer nodes affecting exposed parameters. So it's specific. But wait, the user might think... Wait no, the key is whether it's about a particular issue (specific) or general (generic). The report gives exact steps and a specific context (menu/index switch), so it's specific. But let me confirm: the problem is not vague; it's about viewer nodes in a menu system affecting parameters, which is a specific scenario. So the answer should be Specific? Wait no, wait the example for generic is "Crashing while rendering" which is general. This report has a specific context (menu/index switch), so it's specific. But let me check again. The bug report says "Viewer nodes... affecting exposed parameters in a menu/index switch system." So that's a specific setup. Therefore, the answer is Specific? Wait but wait, maybe I'm overcomplicating. Let's see: the user asks if it's specific or generic. The report has exact steps and a specific context (menu/index switch), so it's specific. But let me check the definitions again. The problem statement says "specific bug reports are about a specific issue. For example: Crashing while using a specific feature while rendering." So this report is about viewer nodes affecting parameters in a menu system, which is a specific feature/setup. So yes, Specific. Wait but wait, maybe I made a mistake. Let me re-read the bug report. The problem says "I am noticing that Viewer nodes, either active or inactive, are affecting exposed parameters regardless of what menu option driving index switches towards the end of my nodes is chosen." So it's about viewer nodes in a menu/index switch system. That's specific. So the answer is Specific? Wait but the user might have thought otherwise. Wait no, let's go with the definitions. The example for generic is vague (crashing while rendering), this is specific (viewer nodes in menu system). So the answer is Specific. But wait, maybe I'm wrong. Let me check again. The bug report has exact steps: "Delete it in 5.0.1 and then in 5.1.0 and you will see what i mean." So that's a specific reproduction step. Therefore, it's a specific issue. So the answer is Specific. Wait but wait, maybe the user thinks it's generic? No, because it's about a particular setup (menu/index switch) with viewer nodes. So yes, Specific.

JSON Data

{
"llm_judgement": true,
"processing_time": 34.218644
}

### Report is specific <details> <summary>LLM Reasoning</summary> Got it, let's figure this out. The question is asking if the bug report is specific or generic. First, let's recall the definitions: specific is about a particular issue (like crashing with a specific feature), generic is vague (like just crashing while rendering). Looking at the bug report: The title mentions "Viewer nodes affecting exposed parameters in a menu/index switch system." The problem describes that viewer nodes are affecting exposed parameters regardless of being active or not, and there's an exact reproduction step (delete the viewer node in different Blender versions). So it's about a specific issue with viewer nodes in a particular setup (menu/index switch system), not a vague "crashing while rendering" type. Wait, but let's check again. The example for generic is "Crashing while rendering" which is vague. This report has a specific scenario: menu/index switch system, viewer nodes affecting exposed parameters. So it's specific. But wait, the user might think... Wait no, the key is whether it's about a particular issue (specific) or general (generic). The report gives exact steps and a specific context (menu/index switch), so it's specific. But let me confirm: the problem is not vague; it's about viewer nodes in a menu system affecting parameters, which is a specific scenario. So the answer should be Specific? Wait no, wait the example for generic is "Crashing while rendering" which is general. This report has a specific context (menu/index switch), so it's specific. But let me check again. The bug report says "Viewer nodes... affecting exposed parameters in a menu/index switch system." So that's a specific setup. Therefore, the answer is Specific? Wait but wait, maybe I'm overcomplicating. Let's see: the user asks if it's specific or generic. The report has exact steps and a specific context (menu/index switch), so it's specific. But let me check the definitions again. The problem statement says "specific bug reports are about a specific issue. For example: Crashing while using a specific feature while rendering." So this report is about viewer nodes affecting parameters in a menu system, which is a specific feature/setup. So yes, Specific. Wait but wait, maybe I made a mistake. Let me re-read the bug report. The problem says "I am noticing that Viewer nodes, either active or inactive, are affecting exposed parameters regardless of what menu option driving index switches towards the end of my nodes is chosen." So it's about viewer nodes in a menu/index switch system. That's specific. So the answer is Specific? Wait but the user might have thought otherwise. Wait no, let's go with the definitions. The example for generic is vague (crashing while rendering), this is specific (viewer nodes in menu system). So the answer is Specific. But wait, maybe I'm wrong. Let me check again. The bug report has exact steps: "Delete it in 5.0.1 and then in 5.1.0 and you will see what i mean." So that's a specific reproduction step. Therefore, it's a specific issue. So the answer is Specific. Wait but wait, maybe the user thinks it's generic? No, because it's about a particular setup (menu/index switch) with viewer nodes. So yes, Specific. </details> <details> <summary>JSON Data</summary> { "llm_judgement": true, "processing_time": 34.218644 } </details>

👍 1

Triager-bot commented

2026-04-12 17:48:13 +00:00

Report flagged as NOT a duplicate by LLM

Unused node will cause menu switch don't hide parameters

https://projects.blender.org/blender/blender/issues/156285

System Information
Operating system: Windows-11-10.0.26100-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 4050 Laptop GPU/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 572.16 Opengl Backend

Blender Version
Broken: version: 5.2.0 Alpha, branch: main, commit date: 2026-03-11 22:42, hash: 81e41f5f73fa
Worked: (newest version of Blender that worked as expected)

Short description of error
The hiding of unused sockets influenced by a menuswitch can get confused by the presense of an identical unconnected menu switch node.

Exact steps for others to reproduce the error

Open the attached menuswitch.blend
connect the bottom menu switch node to the set position node ( or any node, for that matter).
observe the hiding of the unused socket in the group (on the left side) suddenly starts working.

LLM Reasoning

Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce.

Bug report 1: The issue is Viewer nodes affecting exposed parameters in a menu/index switch system. Steps involve deleting a viewer node in different Blender versions to see the effect on exposed parameters.

Bug report 2: Unused node (menu switch) causing menu switch not to hide parameters. Steps involve connecting a menu switch node and observing socket hiding.

The core issues seem different. Report 1 is about Viewer nodes affecting exposed params, Report 2 is about unused sockets in menu switches not hiding due to an unconnected menu switch node. The descriptions don't match, so they're not the same issue. So the answer is No.

JSON Data

{
"llm_judgement": false,
"processing_time": 11.427701,
"duplicate_report_number": "156285"
}

### Report flagged as NOT a duplicate by LLM <details> <summary>Unused node will cause menu switch don't hide parameters</summary> https://projects.blender.org/blender/blender/issues/156285 **System Information** Operating system: Windows-11-10.0.26100-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 4050 Laptop GPU/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 572.16 Opengl Backend **Blender Version** Broken: version: 5.2.0 Alpha, branch: main, commit date: 2026-03-11 22:42, hash: `81e41f5f73fa` Worked: (newest version of Blender that worked as expected) **Short description of error** The hiding of unused sockets influenced by a menuswitch can get confused by the presense of an identical unconnected menu switch node. **Exact steps for others to reproduce the error** - Open the attached [menuswitch.blend](/attachments/49a7d427-ebb2-48e2-86f0-e7bdd6ecabe6) - connect the bottom `menu switch` node to the `set position` node ( or any node, for that matter). - observe the hiding of the unused socket in the group (on the left side) suddenly starts working. </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce. Bug report 1: The issue is Viewer nodes affecting exposed parameters in a menu/index switch system. Steps involve deleting a viewer node in different Blender versions to see the effect on exposed parameters. Bug report 2: Unused node (menu switch) causing menu switch not to hide parameters. Steps involve connecting a menu switch node and observing socket hiding. The core issues seem different. Report 1 is about Viewer nodes affecting exposed params, Report 2 is about unused sockets in menu switches not hiding due to an unconnected menu switch node. The descriptions don't match, so they're not the same issue. So the answer is No. </details> <details> <summary>JSON Data</summary> { "llm_judgement": false, "processing_time": 11.427701, "duplicate_report_number": "156285" } </details>

👍 1

Triager-bot commented

2026-04-12 17:48:25 +00:00

Report flagged as NOT a duplicate by LLM

Regression: Nodes: Double-click on node property can provokate change of editor

https://projects.blender.org/blender/blender/issues/146930

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 576.80 Opengl Backend

Blender Version
Broken: version: 5.0.0 Alpha, branch: main, commit hash: 6ad9bf8af83b0b0a76bf98dfb788e1b0770acc88
Worked: (newest version of Blender that worked as expected)

Short description of error
New feature: if you double-click in node editor now then editor will go up in context path to parent node tree. But this also affect node properties. So if you double click on > button around integer value or on a menu socket then you will be pushed away.

Exact steps for others to reproduce the error

Create integer value node.
Create a group from it.
Gointo the group.
Spam click on arows around value.

LLM Reasoning

Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce.

Bug report 1 is about Viewer nodes affecting exposed parameters in a menu/index switch system. The steps involve deleting a viewer node and seeing the effect on parameters between Blender versions.

Bug report 2 is about double-clicking node properties causing the editor context to change (like going up to parent node tree), which affects things like integer value arrows or menu sockets. The steps are creating an integer node, grouping it, entering the group, and spam clicking arrows.

These issues seem unrelated. One is about Viewer nodes impacting parameters in a switch system, the other is about double-clicking properties changing editor context. So they're not the same issue.

JSON Data

{
"llm_judgement": false,
"processing_time": 11.455597,
"duplicate_report_number": "146930"
}

### Report flagged as NOT a duplicate by LLM <details> <summary>Regression: Nodes: Double-click on node property can provokate change of editor</summary> https://projects.blender.org/blender/blender/issues/146930 **System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 576.80 Opengl Backend **Blender Version** Broken: version: 5.0.0 Alpha, branch: main, commit hash: `6ad9bf8af83b0b0a76bf98dfb788e1b0770acc88` Worked: (newest version of Blender that worked as expected) **Short description of error** New feature: if you double-click in node editor now then editor will go up in context path to parent node tree. But this also affect node properties. So if you double click on `>` button around integer value or on a menu socket then you will be pushed away. **Exact steps for others to reproduce the error** 1. Create integer value node. 2. Create a group from it. 3. Gointo the group. 4. Spam click on arows around value. </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce. Bug report 1 is about Viewer nodes affecting exposed parameters in a menu/index switch system. The steps involve deleting a viewer node and seeing the effect on parameters between Blender versions. Bug report 2 is about double-clicking node properties causing the editor context to change (like going up to parent node tree), which affects things like integer value arrows or menu sockets. The steps are creating an integer node, grouping it, entering the group, and spam clicking arrows. These issues seem unrelated. One is about Viewer nodes impacting parameters in a switch system, the other is about double-clicking properties changing editor context. So they're not the same issue. </details> <details> <summary>JSON Data</summary> { "llm_judgement": false, "processing_time": 11.455597, "duplicate_report_number": "146930" } </details>

👍 1

Triager-bot commented

2026-04-12 17:48:41 +00:00

Report flagged as NOT a duplicate by LLM

Geometry Nodes: Viewer is blocked by top disabled modifier after node tree pinning

https://projects.blender.org/blender/blender/issues/154015

System Information
Operating system: win10
Graphics card: 1050ti

Blender Version
Broken: 5.0.1
Worked:

Short description of error
Stack has 4 geonodes modifiers sharing same node group with different settings. Only 3rd is enabled for execution. Once I've pinned the node tree setup of 3rd modifier in GN editor, Viewer is blocked by 1st modifier. It's not working until I reorder 3rd modifier to the top.

Exact steps for others to reproduce the error
In attached file enable Viewer and turn on Pinned option via pin icon near group name in GN editor. This will trigger Viewer warning: Modifier disabled

LLM Reasoning

Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce.

Bug report 1 is about Viewer nodes affecting exposed parameters in a menu/index switch system. The user says that even when the Viewer node is inactive or deleted, there's an issue with how exposed parameters behave across different Blender versions (5.0.1 vs 5.1.0). The steps involve checking a blend file where deleting the Viewer node shows differences between versions.

Bug report 2 is about Geometry Nodes: Viewer being blocked by a top disabled modifier after pinning the node tree. The issue here is that when you have multiple geo nodes modifiers, and you pin one, the Viewer gets blocked by a disabled modifier higher up in the stack. The steps involve enabling Viewer and pinning the node tree, which triggers a "Modifier disabled" warning.

Now, compare the core issues. Bug 1 is about Viewer nodes affecting exposed parameters (maybe a different behavior with index switches), while Bug 2 is about Viewer being blocked by a disabled modifier when the node tree is pinned. These are different scenarios: one is about parameter exposure and Viewer's effect on them, the other is about Viewer being blocked by modifiers in a stack when pinned. The descriptions don't match, so they're not the same issue.

JSON Data

{
"llm_judgement": false,
"processing_time": 15.154963,
"duplicate_report_number": "154015"
}

### Report flagged as NOT a duplicate by LLM <details> <summary>Geometry Nodes: Viewer is blocked by top disabled modifier after node tree pinning</summary> https://projects.blender.org/blender/blender/issues/154015 **System Information** Operating system: win10 Graphics card: 1050ti **Blender Version** Broken: 5.0.1 Worked: **Short description of error** Stack has 4 geonodes modifiers sharing same node group with different settings. Only 3rd is enabled for execution. Once I've pinned the node tree setup of 3rd modifier in GN editor, Viewer is blocked by 1st modifier. It's not working until I reorder 3rd modifier to the top. **Exact steps for others to reproduce the error** In attached file enable Viewer and turn on Pinned option via pin icon near group name in GN editor. This will trigger Viewer warning: `Modifier disabled` </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce. Bug report 1 is about Viewer nodes affecting exposed parameters in a menu/index switch system. The user says that even when the Viewer node is inactive or deleted, there's an issue with how exposed parameters behave across different Blender versions (5.0.1 vs 5.1.0). The steps involve checking a blend file where deleting the Viewer node shows differences between versions. Bug report 2 is about Geometry Nodes: Viewer being blocked by a top disabled modifier after pinning the node tree. The issue here is that when you have multiple geo nodes modifiers, and you pin one, the Viewer gets blocked by a disabled modifier higher up in the stack. The steps involve enabling Viewer and pinning the node tree, which triggers a "Modifier disabled" warning. Now, compare the core issues. Bug 1 is about Viewer nodes affecting exposed parameters (maybe a different behavior with index switches), while Bug 2 is about Viewer being blocked by a disabled modifier when the node tree is pinned. These are different scenarios: one is about parameter exposure and Viewer's effect on them, the other is about Viewer being blocked by modifiers in a stack when pinned. The descriptions don't match, so they're not the same issue. </details> <details> <summary>JSON Data</summary> { "llm_judgement": false, "processing_time": 15.154963, "duplicate_report_number": "154015" } </details>

👍 1

Triager-bot commented

2026-04-12 17:48:52 +00:00

Report flagged as NOT a duplicate by LLM

Viewer Node can't be disabled

https://projects.blender.org/blender/blender/issues/136910

System Information
Operating system: Windows-10-10.0.26100-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 566.24 Opengl Backend

Blender Version
Broken: version: 4.5.0 Alpha, branch: main, commit date: 2025-04-02 01:20, hash: 144b1a7d56b6
Worked: 4.4.0

Short description of error
The Viewer Node in Geometry Nodes can't be disabled by pressing the eye icon.

Exact steps for others to reproduce the error

Open default startup file
Create a new Geometry Nodes on the default cube
Ctrl+Shift click on the Group Input node to create a Viewer node
Click the eye icon on the Viewer node
Nothing happens, Viewer node is not disabled

LLM Reasoning

Got it, let's analyze these two bug reports. First, look at the descriptions and steps.

Bug report 1: The issue is about Viewer nodes affecting exposed parameters in a menu/index switch system, regardless of active/inactive state. Steps involve deleting the viewer node to see differences between versions.

Bug report 2: The issue is that the Viewer Node can't be disabled via the eye icon (it doesn't respond). Steps are creating a Viewer node and trying to disable it with the eye icon.

The core issues are different. Report 1 is about Viewer nodes impacting parameters in a specific system, while Report 2 is about the eye icon not working to disable the node. So they're not the same issue.

JSON Data

{
"llm_judgement": false,
"processing_time": 10.880317,
"duplicate_report_number": "136910"
}

### Report flagged as NOT a duplicate by LLM <details> <summary>Viewer Node can't be disabled</summary> https://projects.blender.org/blender/blender/issues/136910 **System Information** Operating system: Windows-10-10.0.26100-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 566.24 Opengl Backend **Blender Version** Broken: version: 4.5.0 Alpha, branch: main, commit date: 2025-04-02 01:20, hash: `144b1a7d56b6` Worked: 4.4.0 **Short description of error** The Viewer Node in Geometry Nodes can't be disabled by pressing the eye icon. **Exact steps for others to reproduce the error** - Open default startup file - Create a new Geometry Nodes on the default cube - Ctrl+Shift click on the Group Input node to create a Viewer node - Click the eye icon on the Viewer node - Nothing happens, Viewer node is not disabled </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze these two bug reports. First, look at the descriptions and steps. Bug report 1: The issue is about Viewer nodes affecting exposed parameters in a menu/index switch system, regardless of active/inactive state. Steps involve deleting the viewer node to see differences between versions. Bug report 2: The issue is that the Viewer Node can't be disabled via the eye icon (it doesn't respond). Steps are creating a Viewer node and trying to disable it with the eye icon. The core issues are different. Report 1 is about Viewer nodes impacting parameters in a specific system, while Report 2 is about the eye icon not working to disable the node. So they're not the same issue. </details> <details> <summary>JSON Data</summary> { "llm_judgement": false, "processing_time": 10.880317, "duplicate_report_number": "136910" } </details>

👍 1

Triager-bot commented

2026-04-12 17:49:03 +00:00

Report flagged as NOT a duplicate by LLM

Double clicking node group anywhere goes inside group

https://projects.blender.org/blender/blender/issues/148114

System Information
Operating system: macOS-15.7.1-arm64-arm-64bit 64 Bits
Graphics card: Metal API Apple M4 Max 1.2

Blender Version
Broken: version: 5.0.0 Beta, branch: blender-v5.0-release, commit date: 2025-10-13 10:24, hash: 5460601da340
Worked: 4.5.3

Short description of error
Double clicking node group anywhere goes inside group

Exact steps for others to reproduce the error
double clicking the up or down arrows to increase or decrease field values goes inside node group.
a little annoying when trying to adjust values.
maybe just make double clicking the top of node go inside and everywhere else it doesn't go inside as a fix?
or maybe bring the button back and put the alert icon in the center top?

LLM Reasoning

Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce.

Bug report 1 is about Viewer nodes affecting exposed parameters in a menu/index switch system. The steps involve deleting a viewer node and seeing differences between Blender versions.

Bug report 2 is about double-clicking anywhere on a node group going inside it, especially when adjusting field values (like up/down arrows). The steps are about double-clicking those arrows leading into the group.

These are completely different issues: one is about Viewer nodes and exposed parameters in a menu system, the other is about node group interaction with double-clicks. So they're not duplicates.

JSON Data

{
"llm_judgement": false,
"processing_time": 10.250315,
"duplicate_report_number": "148114"
}

### Report flagged as NOT a duplicate by LLM <details> <summary>Double clicking node group anywhere goes inside group</summary> https://projects.blender.org/blender/blender/issues/148114 **System Information** Operating system: macOS-15.7.1-arm64-arm-64bit 64 Bits Graphics card: Metal API Apple M4 Max 1.2 **Blender Version** Broken: version: 5.0.0 Beta, branch: blender-v5.0-release, commit date: 2025-10-13 10:24, hash: `5460601da340` Worked: 4.5.3 **Short description of error** Double clicking node group anywhere goes inside group **Exact steps for others to reproduce the error** double clicking the up or down arrows to increase or decrease field values goes inside node group. a little annoying when trying to adjust values. maybe just make double clicking the top of node go inside and everywhere else it doesn't go inside as a fix? or maybe bring the button back and put the alert icon in the center top? </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce. Bug report 1 is about Viewer nodes affecting exposed parameters in a menu/index switch system. The steps involve deleting a viewer node and seeing differences between Blender versions. Bug report 2 is about double-clicking anywhere on a node group going inside it, especially when adjusting field values (like up/down arrows). The steps are about double-clicking those arrows leading into the group. These are completely different issues: one is about Viewer nodes and exposed parameters in a menu system, the other is about node group interaction with double-clicks. So they're not duplicates. </details> <details> <summary>JSON Data</summary> { "llm_judgement": false, "processing_time": 10.250315, "duplicate_report_number": "148114" } </details>

👍 1

Triager-bot added

and removed

labels 2026-04-13 14:01:43 +00:00

Sign in to join this conversation.