-
Notifications
You must be signed in to change notification settings - Fork 943
fix(site): fix build logs scrolling on safari #14884
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
Changes from 1 commit
1adeb36
c81a42b
170bc1c
bbb93bb
7a5f53e
8912122
01e66ed
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -24,7 +24,7 @@ import { | |
WorkspaceBuildDataSkeleton, | ||
} from "modules/workspaces/WorkspaceBuildData/WorkspaceBuildData"; | ||
import { WorkspaceBuildLogs } from "modules/workspaces/WorkspaceBuildLogs/WorkspaceBuildLogs"; | ||
import type { FC } from "react"; | ||
import { useLayoutEffect, useRef, type FC } from "react"; | ||
import { Link } from "react-router-dom"; | ||
import { displayWorkspaceBuildDuration } from "utils/workspace"; | ||
import { Sidebar, SidebarCaption, SidebarItem } from "./Sidebar"; | ||
|
@@ -57,6 +57,34 @@ export const WorkspaceBuildPageView: FC<WorkspaceBuildPageViewProps> = ({ | |
defaultValue: "build", | ||
}); | ||
|
||
// TODO: Use only CSS to set the height of the content. | ||
// Note: On Safari, when content is rendered inside a flex container and needs | ||
// to scroll, the parent container must have a height set. Achieving this may | ||
// require significant refactoring of the layout components where we currently | ||
// use height and min-height set to 100%. | ||
// Issue: https://github.com/coder/coder/issues/9687 | ||
// Reference: https://stackoverflow.com/questions/43381836/height100-works-in-chrome-but-not-in-safari | ||
const contentRef = useRef<HTMLDivElement>(null); | ||
useLayoutEffect(() => { | ||
const contentEl = contentRef.current; | ||
if (!contentEl) { | ||
return; | ||
} | ||
|
||
const resizeObserver = new ResizeObserver(() => { | ||
const parentEl = contentEl.parentElement; | ||
if (!parentEl) { | ||
return; | ||
} | ||
contentEl.style.setProperty("height", `${parentEl.clientHeight}px`); | ||
}); | ||
resizeObserver.observe(document.body); | ||
|
||
return () => { | ||
resizeObserver.disconnect(); | ||
}; | ||
}, []); | ||
|
||
if (!build) { | ||
return <Loader />; | ||
} | ||
|
@@ -144,7 +172,10 @@ export const WorkspaceBuildPageView: FC<WorkspaceBuildPageViewProps> = ({ | |
))} | ||
</Sidebar> | ||
|
||
<div css={{ height: "100%", overflowY: "auto", width: "100%" }}> | ||
<div | ||
ref={contentRef} | ||
css={{ height: "100%", overflowY: "auto", width: "100%" }} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we're going to update the height, I think we have no choice put to put the value in render state I just tried making a test component to see what would happen if we don't put height changes in state, and it feels like it's too easy to accidentally wipe the adjustments away
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think I'd do something like this: const [contentHeight, setContentHeight] = useState<string>()
const contentRef = useRef<HTMLDivElement>(null);
useLayoutEffect(() => {
// It's been a while since I've had to do this, but dispatching a state update from the
// resize callback might actually be too slow, and you might get a UI flicker still. You
// might need to set up the resize callback to dispatch state updates, but then also
// do a one-time direct mutation when the effect first mounts
}, [])
css={{ height: contentHeight || "100%" }} |
||
> | ||
<Tabs active={tabState.value}> | ||
<TabsList> | ||
<TabLink to={`?${LOGS_TAB_KEY}=build`} value="build"> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we have an edge case here that could break the effect logic:
Wondering if might be best to make a new component boundary and move this state there. That way, the state only mounts when we're guaranteed to have a build