LogViewer does not initialize styles correctly when its container is hidden on first render (e.g. within the TabContent for a tab that is not initially selected)
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 3/5
- Tempo estimado
- 1-2 dias
- Facilidade para iniciantes
- 45/100
- Tipo de issue
- Bug
- Clareza
- Razoavelmente clara
- Status de atividade
- Estagnada
- Stack de tecnologia
- react, typescript
- Domínio
- frontend
Direção de pesquisa
Start in packages/module/src/LogViewer/LogViewer.tsx, especially createList around the containerRef.current.clientHeight and clientWidth usage. Reproduce the problem with the docs example by initially hiding the LogViewer wrapper, then verify that the list receives correct dimensions when the wrapper becomes visible without a window resize.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
Found while investigating a bug that came up in https://github.com/opendatahub-io/odh-dashboard/pull/2184#discussion_r1399121417 . See related Slack discussion here (Red Hat internal).
We have a set of Tabs with TabContent components. They are rendered the standard way, where all TabContents are rendered regardless of which is active and the non-active tabs get a hidden attribute in the DOM.
One of the tabs which is not the default (its first render gets that hidden attribute) contains a LogViewer. When we switch to the Logs tab and the LogViewer's container becomes visible, the LogViewer's contents appear empty until something else triggers a re-render (such as resizing the window). However, if we change the code so that the Logs tab is the default tab (the LogViewer's first render is in a container that is not hidden), it works as expected.
This appears to be happening because of the way containerRef.current.clientHeight and .clientWidth are used in the createList function here. clientHeight and clientWidth resolve to 0 for hidden elements, so the List gets rendered with 0 height and 0 width. The container changing from hidden to non-hidden does not trigger a re-render in the LogViewer, so the List only gets its height and width set correctly when createList is called again after something else triggers a re-render.
One possible solution to this would be to add some kind of listener or observer that can detect that the containerRef.current element has become visible and have it trigger a re-render similarly to how resizing the window does. This could be done with an IntersectionObserver as described in this blog post.
I was able to reproduce the bug in the docs example here by opening the source of the basic example and editing it to have an additional "hidden" checkbox which defaults to true and applies a hidden attribute on a <div> wrapping the LogViewer. I would link a CodeSandbox showing this but it appears the sandbox generator on the site is broken (at least for this example). Adding an IntersectionObserver in the console while reproducing it in this way, I can detect that visibility changing.
Jira Issue: FELT-1446
- Linguagem predominante
- TypeScript
- Estrelas
- 34
- Forks
- 19
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de patternfly/react-log-viewer
-
Search within Log viewer can cause the parent container to shift and break the layout, when embedded in a scrollable parentTalvez já em andamento @fao89 assumiu há 161 dias. Aberta
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 67/100
patternfly/react-log-viewer#106 ·
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 45/100
patternfly/react-log-viewer#101 ·
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 25/100
patternfly/react-log-viewer#98 · 1 comentário ·
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 25/100
patternfly/react-log-viewer#95 · 2 comentários ·
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 35/100
patternfly/react-log-viewer#91 · 1 comentário ·
Todas as issues de patternfly/react-log-viewer
Issues semelhantes
-
Chip source filter and denial markers miss Storage rows when a Storage activity source is pickedAbertabug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 77/100
omdsh-dev/DSH-better-sidebar#1141 ·
Mantenedores costumam responder em até 2 dias
-
desktop linux photos
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
Mantenedores costumam responder em até 1 dia
-
Cleanup SetupTalvez já em andamento @AlexanderKaran assumiu hoje. Abertadocumentation enhancement
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 64/100
e18e/framework-tracker#769 ·
Mantenedores costumam responder em até 1 dia
-
fix(docker): correct stale --db-path comments in fetch/git Dockerfiles and clarify git READMEAbertabug v2
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 88/100
modelcontextprotocol/servers#5483 ·
Mantenedores costumam responder em até 1 dia