ID 401016 - Running Gizmo.filename() will return the value of a gizmo's file knob, rather than the location the gizmo is saved to

Problem summary
Running Gizmo.filename() will return the value of a gizmo's file knob, rather than the location the gizmo is saved to.

This behaviour appears to have been introduced in Nuke 11.3v1.

Customer reported version
Nuke 11.3v4

Customer reported platform
CentOS 7

Steps to reproduce

1) Save the following as a gizmo in your ~/.nuke directory:

#! C:/Program Files/Nuke11.3v4/nuke-11.3.4.dll -nxversion 11.3 v4Gizmo { addUserKnob {20 User} addUserKnob {2 file}} Input {  inputs 0  name Input1  xpos 173  ypos -10 } Write {  file "\[value parent.file]"  name Write1  xpos 173  ypos 30 } Output {  name Output1  xpos 173  ypos 130 }end_group

2) Create the Gizmo in the Node Graph. You can do this by running the following line of code in the Script Editor:

nuke.createNode('test')

3) Next, run the following line in the Script Editor:

nuke.toNode('gizmo_name').filename()

And notice that the filepath where the gizmo is saved will be returned.

4) Then run the following line in the Script Editor:

nuke.toNode('gizmo_name')['file'].setValue('path/to/write/images')

This will set the a path on the gizmo's file knob.

5) Run the following line of code again:

nuke.toNode('gizmo_name').filename()

Notice that the filepath from the custom file knob will now be returned.

Expected behaviour
Gizmo.filename() should return the filename and directory that the gizmo is saved to.

Actual behaviour
When the gizmo's custom file knob has a value, it will be returned by running Gizmo.filename()

Reproduced by support

This bug has been reproduced in:

Nuke 12.2v3 - Windows 10 - macOS 10.14 (Mojave) - Linux CentOS 7

Nuke 11.3v4 - Windows 10 - macOS 10.13 (High Sierra) - Linux CentOS 7 

Nuke 11.3v1 - Windows 10 - macOS 10.13 (High Sierra) - Linux CentOS 7 - Regression

Unable to reproduce bug in:
Nuke 11.2v6 - Windows 10 - macOS 10.13 (High Sierra) - Linux CentOS 7 

Earliest version tested
Nuke 11.2v6
- This issue no longer appears in this version and has regressed