New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Search plugin crashes for h[1-6]
contained in other elements
#4824
Comments
Thanks for reporting. Great report and reproduction! While it is good to know that hoisting the headlines fixes the problem, I think we need to do some thinking how to handle nested headlines, as this is likely something that may occur. For example, headlines may be contained in admonitions or other block elements, which would lead to the same problem. Your suggested fixes would likely break the search, as now there are unbalanced HTML tags in the search index. As a possible solution, we could only include the tags in a search index section that appear on the same level as the headline. However, we would also need to take care of content that happens after a nested block with a headline is closed and before the next headline: <div class="admonition">
<h2>Headline</h2>
<p>This would be indexed, but would need to be hoisted</p>
</div>
<p>This also needs to be indexed</p>
<h2>Next headline</h2> This will likely take a little time to fix. |
h1...6
contained in other elements
h1...6
contained in other elementsh[1-6]
contained in other elements
I've generalized the title, so it's easier to find for other users. |
We also ran into this. Additionally, numbered lists immediately followed by an octothorpe also caused this problem for us. ex: We also found some docs with an empty list items, that caused a similar error with the search plugin. ( let me know if you want a separate issue opened?) We ended up just cleaning up the docs but didn't have this issue on 8.x. - NetApp SnapDrive/LUN vs VMDK
-
|
Fixed in 81e7b8c. Interesting problem! This was tricky, but I think I found a generalizable solution. The search plugin will now track the depth of sections when parsing, and attribute content to the nearest unclosed section. A section is considered closed, once it's exited. Now, nested headlines should work without any problems. I'm now looking into a better approach for filtering empty paragraphs and tags that is more resilient, which I removed temporarily to fix the nesting problem first. Expect a fix later today. Example: # Example
- ## List
!!! info "Admonition title"
Admonition content (before)
### Admonition
Admonition content (after)
List content 1
- ### Nested list
Nested list content
List content 2
Some other text
## Foo
Bar
!!! info "Admonition title 2"
Admonition content 2 (before)
# Admonition 2
Admonition content 2 (after) Result: {
// ...
"docs": [
{
"location": "",
"title": "Example",
"text": "<ul> <li> </li> </ul> <p>Some other text</p>"
},
{
"location": "#list",
"title": "List",
"text": "<p>Admonition title</p> <p>Admonition content (before)</p> <p>List content 1</p> <ul> <li> </li> </ul> <p>List content 2</p>"
},
{
"location": "#admonition",
"title": "Admonition",
"text": "<p>Admonition content (after)</p>"
},
{
"location": "#nested-list",
"title": "Nested list",
"text": "<p>Nested list content</p>"
},
{
"location": "#foo",
"title": "Foo",
"text": "<p>Bar</p> <p>Admonition title 2</p> <p>Admonition content 2 (before)</p>"
},
{
"location": "#admonition-2",
"title": "Admonition 2",
"text": "<p>Admonition content 2 (after)</p>"
}
]
} |
6825734 makes collapsing of adjacent whitespace and removal of empty elements more resilient. This results in the following, more compact search index that only includes paragraphs with content: {
// ...
"docs": [
{
"location": "",
"title": "Example",
"text": "<p>Some other text</p>"
},
{
"location": "#list",
"title": "List",
"text": "<p>Admonition title</p> <p>Admonition content (before)</p> <p>List content 1</p> <p>List content 2</p>"
},
{
"location": "#admonition",
"title": "Admonition",
"text": "<p>Admonition content (after)</p>"
},
{
"location": "#nested-list",
"title": "Nested list",
"text": "<p>Nested list content</p>"
},
{
"location": "#foo",
"title": "Foo",
"text": "<p>Bar</p> <p>Admonition title 2</p> <p>Admonition content 2 (before)</p>"
},
{
"location": "#admonition-2",
"title": "Admonition 2",
"text": "<p>Admonition content 2 (after)</p>"
}
]
} Additionally, the case with empty lists reported by @defenestration doesn't crash the plugin. |
Released as part of 9.0.3. |
Context
Our CI recently pulled in the newly released 9.0.1 this week; the build for one of our sites started failing afterwards.
Bug description
We have some old (non-ideal) markdown that crashes the search plugin during indexing:
The markdown that results in this is a section header in a list:
... disabling the
search
plugin, that snippet results in this HTML:It's entirely possible that this is "invalid" markdown - however, this did "work" (not crash) with previous releases (including 8.5.11).
We have no real need for that that hierarchy (I suspect it was originally a typo), so I've updated our site to remove the bullet points. It took some digging (aided by
breakpoint()
:)) to narrow down which part of the file was triggering the crash.Changing
mkdocs-material/material/plugins/search/plugin.py
Line 417 in c8fb426
len(data) >= 2
results in a successful build, although I'm not sure the generated search index makes sense:Related links
Reproduction
example.zip
Steps to reproduce
Run
mkdocs build
with the attached zip (probably need to removeinfo
from the mkdocs.yml)Browser
No response
Before submitting
The text was updated successfully, but these errors were encountered: