(Note that Bug 1571349 will hide the issue, so when it lands you need to make sure to use a prior changeset) The STRs: - open a first tab on https://sugared-oil.glitch.me/ (this page contains ~2000 CSS warnings, CSS warnings seem much heavier to render than normal messages) - open a second tab on about:debugging - select `This Nightly` - find the tab corresponding to `sugared-oil.glitch.me` (note, if this is not a local build, you have to enable local tab debugging by flipping `devtools.aboutdebugging.local-tab-debugging` to true) - click on inspect - in the about:devtools-toolbox tab that just opened, select the Console panel - in the console filters enable CSS Warnings, `CSS` in the filter bar - hover on the message list ER: The messages should not become blank after hover AR: Messages are blank after hover (https://devtools-html.slack.com/files/U42HDB04Q/FM20KMV6C/console_message_over_content_frame.mp4) If you try to open the regular DevTools on https://sugared-oil.glitch.me/, hovering the messages will be slow, but lines will not go blank. The reason I am using about:debugging+about:devtools-toolbox for the test case is that it forces the toolbox to load in a frame with type="content" instead of "chrome". But I actually found the issue while working on Bug 1539979, and I had the issue in the regular toolbox as soon as I set "type" to "content" for the toolbox frame. So about:debugging/about:devtools-toolbox recreates a similar environment, but it's something that might happen to regular DevTools as soon as we land Bug 1539979. We recorded two profiles: - content frame: https://perfht.ml/2KoQBPK - chrome frame: https://perfht.ml/2KvvefN And Nicolas also extracted a comparison: https://profiler.firefox.com/compare/stack-chart/?globalTrackOrder=0-1-2&profiles[]=https%3A%2F%2Fperfht.ml%2F31fPOaE&profiles[]=https%3A%2F%2Fperfht.ml%2F31gMKeq&thread=0&v=4 So it seems reflow/rendering is behaving differently depending on the frame type.
Bug 1571644 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(Note that Bug 1571349 will hide the issue, so when it lands you need to make sure to use a prior changeset) ## STRs - open a first tab on https://sugared-oil.glitch.me/ (this page contains ~2000 CSS warnings, CSS warnings seem much heavier to render than normal messages) - open a second tab on about:debugging - select `This Nightly` - find the tab corresponding to `sugared-oil.glitch.me` (note, if this is not a local build, you have to enable local tab debugging by flipping `devtools.aboutdebugging.local-tab-debugging` to true) - click on inspect - in the about:devtools-toolbox tab that just opened, select the Console panel - in the console filters enable CSS Warnings, `CSS` in the filter bar - hover on the message list ER: The messages should not become blank after hover AR: Messages are blank after hover (https://devtools-html.slack.com/files/U42HDB04Q/FM20KMV6C/console_message_over_content_frame.mp4) ## Additional info If you try to open the regular DevTools on https://sugared-oil.glitch.me/, hovering the messages will be slow, but lines will not go blank. The reason I am using about:debugging+about:devtools-toolbox for the test case is that it forces the toolbox to load in a frame with type="content" instead of "chrome". But I actually found the issue while working on Bug 1539979, and I had the issue in the regular toolbox as soon as I set "type" to "content" for the toolbox frame. So about:debugging/about:devtools-toolbox recreates a similar environment, but it's something that might happen to regular DevTools as soon as we land Bug 1539979. ## Profiles We recorded two profiles: - content frame: https://perfht.ml/2KoQBPK - chrome frame: https://perfht.ml/2KvvefN And Nicolas also extracted a comparison: https://profiler.firefox.com/compare/stack-chart/?globalTrackOrder=0-1-2&profiles[]=https%3A%2F%2Fperfht.ml%2F31fPOaE&profiles[]=https%3A%2F%2Fperfht.ml%2F31gMKeq&thread=0&v=4 So it seems reflow/rendering is behaving differently depending on the frame type.
(Note that Bug 1571349 will hide the issue, so when it lands you need to make sure to use a prior changeset) ## STRs - open a first tab on https://sugared-oil.glitch.me/ (this page contains ~2000 CSS warnings, CSS warnings seem much heavier to render than normal messages) - open a second tab on about:debugging - select `This Nightly` - find the tab corresponding to `sugared-oil.glitch.me` (note, if this is not a local build, you have to enable local tab debugging by flipping `devtools.aboutdebugging.local-tab-debugging` to true) - click on inspect - in the about:devtools-toolbox tab that just opened, select the Console panel - in the console filters enable CSS Warnings, `CSS` in the filter bar - hover on the message list ER: The messages should not become blank after hover AR: Messages are blank after hover (https://bug1571644.bmoattachments.org/attachment.cgi?id=9083257) ## Additional info If you try to open the regular DevTools on https://sugared-oil.glitch.me/, hovering the messages will be slow, but lines will not go blank. The reason I am using about:debugging+about:devtools-toolbox for the test case is that it forces the toolbox to load in a frame with type="content" instead of "chrome". But I actually found the issue while working on Bug 1539979, and I had the issue in the regular toolbox as soon as I set "type" to "content" for the toolbox frame. So about:debugging/about:devtools-toolbox recreates a similar environment, but it's something that might happen to regular DevTools as soon as we land Bug 1539979. ## Profiles We recorded two profiles: - content frame: https://perfht.ml/2KoQBPK - chrome frame: https://perfht.ml/2KvvefN And Nicolas also extracted a comparison: https://profiler.firefox.com/compare/stack-chart/?globalTrackOrder=0-1-2&profiles[]=https%3A%2F%2Fperfht.ml%2F31fPOaE&profiles[]=https%3A%2F%2Fperfht.ml%2F31gMKeq&thread=0&v=4 So it seems reflow/rendering is behaving differently depending on the frame type.
(Note that Bug 1571349 will hide the issue, so when it lands you need to make sure to use a prior changeset) ## STRs - open a first tab on https://sugared-oil.glitch.me/ (this page contains ~2000 CSS warnings, CSS warnings seem much heavier to render than normal messages) - open a second tab on about:debugging - select `This Nightly` - find the tab corresponding to `sugared-oil.glitch.me` (note, if this is not a local build, you have to enable local tab debugging by flipping `devtools.aboutdebugging.local-tab-debugging` to true) - click on inspect - in the about:devtools-toolbox tab that just opened, select the Console panel - in the console filters enable CSS Warnings, `CSS` in the filter bar - hover on the message list ER: The messages should not become blank after hover AR: Messages are blank after hover ([see attached video](https://bug1571644.bmoattachments.org/attachment.cgi?id=9083257)) ## Additional info If you try to open the regular DevTools on https://sugared-oil.glitch.me/, hovering the messages will be slow, but lines will not go blank. The reason I am using about:debugging+about:devtools-toolbox for the test case is that it forces the toolbox to load in a frame with type="content" instead of "chrome". But I actually found the issue while working on Bug 1539979, and I had the issue in the regular toolbox as soon as I set "type" to "content" for the toolbox frame. So about:debugging/about:devtools-toolbox recreates a similar environment, but it's something that might happen to regular DevTools as soon as we land Bug 1539979. ## Profiles We recorded two profiles: - content frame: https://perfht.ml/2KoQBPK - chrome frame: https://perfht.ml/2KvvefN And Nicolas also extracted a comparison: https://profiler.firefox.com/compare/stack-chart/?globalTrackOrder=0-1-2&profiles[]=https%3A%2F%2Fperfht.ml%2F31fPOaE&profiles[]=https%3A%2F%2Fperfht.ml%2F31gMKeq&thread=0&v=4 So it seems reflow/rendering is behaving differently depending on the frame type.