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
theme-f1 chromeless logs template updates #6965
theme-f1 chromeless logs template updates #6965
Conversation
This might have been introduced by #6663, but the log warning needs some padding. |
@@ -1,17 +1,27 @@ | |||
<default-header class="top-header"></default-header> | |||
<div column flex class="content"> | |||
<div flex class="log-chromeless"> |
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.
We should remove log-chromeless
from the less file if not used.
The follow link positioning doesn't seem to be specific to chromeless logs. Is that where it was before? |
@spadgett no it was definitely right-aligned before |
I think it was because we removed the
|
Yeah thats weird. I'll look at that as well. |
The right alignment is an easy fix. However, the "sticky" behavior is tricky because it uses bootstrap |
@benjaminapetersen we can fix the sticky behavior in another PR |
724ca0e
to
a302df7
Compare
@spadgett sounds good, will pass on that. I had already done a minor update to the affix directive, but will leave it as is at this point. |
@@ -76,6 +77,10 @@ | |||
} | |||
} | |||
|
|||
.chromeless .log-scroll-top.affix { | |||
right: 0px; // override | |||
} |
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.
Is .log-chromeless
still defined? We should remove that and carry over the style that adds margin to the log length warning.
Let's open an issue to track the affix problem. |
(moving list to description) |
If you put Fixes #<number> in the description, it'll automatically close the issue when merged. I think it needs to be in a description, not a comment. |
ah, nice. ok ill update that. |
a302df7
to
0771431
Compare
@spadgett @jwforres @sg00dwin ready for review. Only thing to note is affix has at least one lingering issue. It now functions again on normal/chromeless views, and works mobile & non-mobile. However, on a resize between mobile-non-mobile, it struggles to continue to work properly. A page refresh will get it working again. I tried a number of different things but wasn't able to find a workable solution to this (note resize to mobile "breaks", but resize back to full view will work again, or vice-versa). |
Oh let me kill that css line & fix that alert padding... got excited about affix & almost forgot those. |
} | ||
}); | ||
} | ||
}; |
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.
Have you tried adding $affixableNode.affix('checkPosition')
?
This method needs to be called whenever the dimensions of the affixed content or the target element are changed, to ensure correct positioning of the affixed content.
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.
Yup. It doesn't register the target update so that causes more weird positioning.
Also tried .data('bs.affix').options.target
per this SO article. Was optimistic with this one since the fix suggested is by one of the BS creators 😄
@smarterclayton for 1.1.2 |
attachScrollEvents(); | ||
updateScrollLinks(); | ||
affix(); | ||
}); |
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.
Don't we need to pass a value for wait
to debounce
?
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.
Looks like it was 50 before.
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.
Oop, yeah, good catch. Don't want to miss that. it defaults to 0 if just wanting to kick it up the stack, but def want a real delay here. fixing. Was 50, setting to 100. 200 even seemed reasonable when testing.
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.
updated
0771431
to
d529a0d
Compare
- fixes hamburger menu collapsing on chromeless pages - fixes follow/end link placement on chromeless pages - provides pass-through configuration option on log-viewer for underlying affix directive - TODO: more work is needed to get this in all contexts, but mobile seems to function - fixes a handful of the affix issues - optimizes DOM manipulation while logs running - fix alert padding on chromeless page
d529a0d
to
d9f2b73
Compare
[merge] |
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/829/) (Image: devenv-rhel7_3339) |
Evaluated for origin merge up to d9f2b73 |
[Test]ing while waiting on the merge queue |
Evaluated for origin test up to d9f2b73 |
continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/829/) |
…omeless-logs-fix Merged by openshift-bot
At some point in the near future we should encapsulate the scrolling functionality better. It's fairly brittle & prone to breaking w/o being noticed. I left comments in the
chromeless-build-log.html
file for future reference.Checklist of bugs intending to addressed:
So to let github handle closing issues when merged:
fixes #6956
fixes #6985
fixes #6957
fixes #7003
@sg00dwin @spadgett