UI issue in the "tree view" if directory called "notebooks" is in the path.

[avloss]

Description

Getting a pesky warning in the "tree" view, if path to the directory includes "notebooks"(with that exact spelling).

Reproduce

1. Create a path that includes "notebooks", and has sub-directories. ("http://localhost:8888/tree/test/notebooks/test")
2. Navigate to that path via UI tree view.
3. Click Refresh
4. Get a pesky warning:

File Load Error for test
Invalid response: 404 Not Found

5. Renaming directory "notebooks" to LITERALLY ANYTHING (including capitalising any of the letters) removes the issue.

Expected behavior

No warning happens

[jtpio]

Thanks @avloss for reporting the issue 👍

Just to double check, which version of Notebook 7 are you using?

[avloss]

Thanks @avloss for reporting the issue 👍

Just to double check, which version of Notebook 7 are you using?

notebook==7.0.7

[SATOSHIFNAKAMOTO]

Hello all 👋,

I've been able to reproduce the "tree view" issue on my end. After navigating to the /test/notebooks/test directory in the Jupyter Notebook UI, I clicked the browser's refresh button (specifically in Firefox, not the Jupyter in-app refresh), and I encountered the "File Load Error for test" stating "test is a directory, not a file".

Here's the detailed setup I'm working with:

Jupyter Notebook version: 7.1.0a2
Operating System: macOS 13.6.3 (22G436)
Browser: Firefox 121.0.1 (64-bit)
Attached is a screenshot showing the error message that appeared. It seems that the browser refresh is being misinterpreted, leading to this unexpected error. Has anyone had a similar experience, or does anyone have insights on what might be causing this behavior?

Best,
Satoshi 中本哲史

[itsmevichu]

Hi @jtpio, I'm new to open source and very excited to contribute. I'd like to work on this issue. I have made a root cause analysis and here are the observations;

Background:

The current problem arises because the handlers are activated whenever specific keywords, namely {“notebooks”, “edits”, ”consoles”, ”terminals”}, are found in the path. This leads to undesired behaviour when directories with these keywords are present.

For instance:

• Accessing http://localhost:8888/tree/mydir/notebooks/temp/ results in a 404 - file not found error, as the NotebookHandler expects an ipynb file.
• Accessing http://localhost:8888/tree/mydir/edits/temp/ also triggers a 404 - file not found error
• Accessing http://localhost:8888/tree/mydir/terminals/temp/ opens a Terminal.
• Accessing http://localhost:8888/tree/mydir/consoles/temp/ opens a Console.

Potential Solutions:

1. Modify the regex of the handlers to activate only when the respective keyword is present at the beginning of the path.
   For example: NotebookHandler should only be activated when http://localhost:8888/**notebooks**/, not on http://localhost:8888/tree/**notebooks**/.
2. Considering that these handlers are applied sequentially in the order they are appended, a quick workaround could involve appending the tree handler at the end (though not recommended).
   

If you have any alternative ideas, please share them, and I'll explore them further to address the issue.

[jtpio]

Thanks @itsmevichu for looking into this 👍

Yes it looks like there is an issue with how the handlers are set up. If you feel like opening a PR (even as a draft) to investigate these solutions, that would be great! That way it can be more easily tested, and maybe we can also look into adding a test to cover this case.

Thanks!

[itsmevichu]

Sure @jtpio, I will create a PR and let you know.

[itsmevichu]

@jtpio I have raised a PR #7253 please look into it.

[jtpio]

Thanks @avloss for reporting the issue 👍

Just to double check, which version of Notebook 7 are you using?

[avloss]

Thanks @avloss for reporting the issue 👍

Just to double check, which version of Notebook 7 are you using?

notebook==7.0.7

[SATOSHIFNAKAMOTO]

Hello all 👋,

I've been able to reproduce the "tree view" issue on my end. After navigating to the /test/notebooks/test directory in the Jupyter Notebook UI, I clicked the browser's refresh button (specifically in Firefox, not the Jupyter in-app refresh), and I encountered the "File Load Error for test" stating "test is a directory, not a file".

Here's the detailed setup I'm working with:

Jupyter Notebook version: 7.1.0a2
Operating System: macOS 13.6.3 (22G436)
Browser: Firefox 121.0.1 (64-bit)
Attached is a screenshot showing the error message that appeared. It seems that the browser refresh is being misinterpreted, leading to this unexpected error. Has anyone had a similar experience, or does anyone have insights on what might be causing this behavior?

Best,
Satoshi 中本哲史

[itsmevichu]

Hi @jtpio, I'm new to open source and very excited to contribute. I'd like to work on this issue. I have made a root cause analysis and here are the observations;

Background:

The current problem arises because the handlers are activated whenever specific keywords, namely {“notebooks”, “edits”, ”consoles”, ”terminals”}, are found in the path. This leads to undesired behaviour when directories with these keywords are present.

For instance:

• Accessing http://localhost:8888/tree/mydir/notebooks/temp/ results in a 404 - file not found error, as the NotebookHandler expects an ipynb file.
• Accessing http://localhost:8888/tree/mydir/edits/temp/ also triggers a 404 - file not found error
• Accessing http://localhost:8888/tree/mydir/terminals/temp/ opens a Terminal.
• Accessing http://localhost:8888/tree/mydir/consoles/temp/ opens a Console.

Potential Solutions:

1. Modify the regex of the handlers to activate only when the respective keyword is present at the beginning of the path.
   For example: NotebookHandler should only be activated when http://localhost:8888/**notebooks**/, not on http://localhost:8888/tree/**notebooks**/.
2. Considering that these handlers are applied sequentially in the order they are appended, a quick workaround could involve appending the tree handler at the end (though not recommended).
   

If you have any alternative ideas, please share them, and I'll explore them further to address the issue.

[jtpio]

Thanks @itsmevichu for looking into this 👍

Yes it looks like there is an issue with how the handlers are set up. If you feel like opening a PR (even as a draft) to investigate these solutions, that would be great! That way it can be more easily tested, and maybe we can also look into adding a test to cover this case.

Thanks!

[itsmevichu]

Sure @jtpio, I will create a PR and let you know.

[itsmevichu]

@jtpio I have raised a PR #7253 please look into it.