Our team (not only my computer) has a wierd rendering issue for Angular 2, that only happens in Chrome.
Namely, when navigating the app or refreshing in mid app, many of the items in DOM are invisible. EG. paragraphs and headers that have text in them, but the text is not rendered for the end user, but the text is seen in the inspector DOM.
The DOM will regain visibility if you edit a random CSS attribute in the inspector. This CSS doesnt even have to be applicable to the invisible DOM item at hand, ala. the invisible item could be a paragraph in the header, and switching a random footer span-s top position on/off will make the header paragraph regain visibility.
Before toggling a random CSS element
After toggling a random CSS element
This happens on pages that have a fixed loader applied to them, eg. a component that has position fixed, a superhigh z-index and encompasses the whole screen. This page loader is displayed until ngOnInit finishes, meaning it is pretty fast most of the time. Disabling this loader seems to fix the issue.
This also sometimes happens to text in {{ var }} tags, when the var value is loaded after the page has loaded.
We have tried toggling the loader with either
*ngIf="true/false"
OR
[style.display]="block/none"
Neither of these solutions work, some of the dom is still invisible.
Does anyone have a clue as to why this happens?
I think this question has been answered here: custom #font-face does not load in chrome (chrome custom fonts not rendering)
I have done a quick test and it seems to have fixed things.
Basically I was including the custom font many times (each time a SCSS file was added to a component), so I have moved it, so it's only being loaded a single time, and it now loads fine.
The issue is multiple inclusion in google chrome, I face similar issue when using angular4 and material lite.The problem is i imported fonts in every component and fixed it by importing font in single main parent component.
Related
I have a webpage on which if a tab key is pressed when in the last textbox a side pane from the right slides(like a side menu).
In chrome development tools I can see it is an aside tag with classes control-sidebar control-sidebar-dark but setting DOM break points(subtree & attribute) on the aside tag is not capturing anything.
On looking into DOM it seems like it is not being manipulated at all(which I expected sliding in should be doing) as I do not see the color blink on HTML tags that chrome developer tool shows for the affected elements.
I was expecting the javascript to be handling the sliding in of the aside tag but how could it be determined in this scenario? Could this be due to CSS only animation or something if yes than how to debug that?
I also tried to record in the animation tab of developer tools but it also stays blank.
This is happening on a privileged section of the site so I m sorry for not being able to put code sample or URL.
PS: The template is some modified version of http://www.ampleadmin.wrappixel.com/ampleadmin-html/ampleadmin-rtl/index.html(the navigation panel on right) but it is getting recorded in dev tool animation panel while mine doesnt.
I found out the cause. There are anchor tags inside the panel which get focused on when the tab is pressed from last textbox. There was no animation,CSS or JS involved.
Anchor(A) tags are focus able by default and the panel dont slide in when they are removed.
I'm running into something really weird with my HTML/CSS.
When I reload the page sometimes one of my elements ends up positioned where it's supposed to be (centered vertically) and sometimes it ends up out of the viewport (something like 700px above the top of the page).
That the page acts differently on different page loads is only half of the weirdness. If I remove body's height: 100% property and re-add it in the web inspector everything magically fixes itself. (body is this element's direct parent.)
My instinct tells me that the answer to the first part of the weirdness is that there's some race condition going on causing things to happen in a different order randomly. But I'm not sure what that might be or why it's affecting things.
What could cause removing and re-adding an identical CSS attribute from an element to cause the page layout to change?
I can't reproduce in a jsfiddle unfortunately but here's a gif of this in action:
Edit: A new piece of the puzzle. I've discovered that this only happens in Chrome and appears to happen only if the page is loaded with an empty hash on the URL.
http://myurl.com works
http://myurl.com/#foo works
http://myurl.com/# intermittently has issues
There was a workaround to trigger a re-flow posted by #Huangism below but there are some caveats (some complications with timing when exactly to trigger a re-flow and also triggering a re-flow on a working page causes a flash of the content).
I think this is a weird bug with chrome, try this
After the content is shown, using jquery - hide the div that contains that content, check it's height and show it
Assuming $el is your jquery div element
$el.hide().height();
$el.show();
Try it and see if it fixes the issue or not
Try setting the height using js or jquery.
It looks like when you reload the page your CSS attributes are set to your body tag via style="" and then quickly removed. Its likely something in your js
Good grief this is hacky. Would still love an explanation for exactly what's going on and the proper way to deal with it but...
After figuring out that somehow an empty hash being appended to the URL was part of the issue an acceptable workaround seems to be completely removing an empty hash if present by using the html5 history API.
My code looks something like this:
// when the page is ready...
$(function() {
// if the url ends with a "#" (and the browser supports it...)
if(window.location.href && window.location.href.indexOf('#') == window.location.href.length - 1 && window.history) {
// clear the darn empty hash using the html5 history API
window.history.replaceState({}, '', './');
}
});
I've been asked to fix a few bugs on a website, and one of them is throwing me for a loop. Due to the style layout of this particular site, when a user selects and copies text from a specified area, they copy rich text data which if pasted into a rich text editor, results in a large black text on black-background blob.
Ideally, I would like to strip all style data, or somehow enable plain text copying on a particular set of data.
Is this possible? Or would I have to resort to something like a a Flash applet like what GitHub uses for Git URLs?
If you're happy with using JavaScript to solve the problem you can capture the "oncopy" events (credit to #FirstZero) on the elements you wish to restyle, and then restyle the element using JavaScript and style it back again after a timeout.
If you are okay using jQuery you can use JavaScript similar to the following:
$('p').bind(
'copy',
function(e) {
var copyElem= $(e.target);
var defaultColor = copyElem.css('color');
copyElem.css('color', 'pink'); // Change the color to pink for copy
window.setTimeout(
function() {copyElem.css('color', defaultColor);}, // Change it back
1
);
}
);
(Try it out in jsFiddle)
Note that this would be neater if there existed an onaftercopy event, but unfortunately there doesn't seem to.
I've only tested the above solution in Chrome, but it should work in Firefox (since 3.0), latest versions of Chrome and Safari, and in Internet Explorer. It will probably not work in Opera.
Many many years ago, I made a custom form that replicated the look of a menu on a video game. At the time, Firefox didn't allow many form UI widgets (Firefox 2.something?) to be styled with CSS. Apparently in the last few years that has changed.
What I wound up doing to resolve this problem was creating a very large input text-box with the content passed in via the value="" attribute. (<input type="text", not <textarea)
Despite the ability to style input boxes and their content, this information is not retained when copying the text itself. So I completely side-stepped the issue, and the fixes are live!
It was quite a bit simpler too, absolutely no-JS required.
I was delighted to discover that Android 2.2 supports the position:fixed CSS selector. I've built a simple proof-of concept, here:
http://kentbrewster.com/android-scroller/scroller.html
... which works like a charm. When I attempt to add an INPUT tag to my header, however, I hit trouble. On focus, every device I've tried so far clones the INPUT tag, gives it an infinite Z-index, and repaints it on top of the old tag. The clone is in roughly the right position, but most of its parent's CSS (including, of course, position:fixed) is ignored. The cloned INPUT tag is the wrong size and shape, and when I scroll the body of the page, it scrolls up and off the screen.
Once it's off screen, hilarity ensues. Sometimes the device will force the scrolling part of the body back down so the cloned blank is back in view; sometimes the keyboard goes away even though the visible box seems to remain in focus; sometimes the keyboard cannot be dismissed even though the INPUT blank is clearly blurred. Here's an example you can run on your Android 2.2 device to see what's happening:
http://kentbrewster.com/android-input-style-bug/
Styling input:focus has not done the trick for me yet, nor have many different brute-force attempts to listen for focus() and blur() with JavaScript and do the right thing with focus and the keyboard.
Thanks very much for your help,
--Kent
This will probably not be resolved until Android switches to using Chrome for its WebView. The current Android browser creates an Android TextView on top of the page when an HTML input field is focussed. Apparently they don't style or position it correctly. You can see it go more wrong on pages that use contentEditable.
The current Chrome-for-Android implements the WebKit IME interface, so input fields are drawn by WebKit (and lose some of the niceties of the Android TextView on ICS) and shouldn't have issues like this.
The solution is to add:
input {
-webkit-user-modify: read-write-plaintext-only;
-webkit-tap-highlight-color: rgba(255,255,255,0);
}
in your css.
You might be able to solve it by using a bug in Android: http://code.google.com/p/android/issues/detail?id=14295.
That is, don't display the input field right away. Instead, display an overlay div which listens on click and hides itself and shows the hidden input, and give the input focus. This somehow prevents Android from using the wierd input that gets placed on top of everything, and is instead using the browsers input field which you can style any way you want.
As you'll note in the bug raport though, this doesn't work with input[type="number"]...
We have a page where a PDF is embedded, and are trying to pop drop-down menus, jQuery UI dialogs, etc. over the PDF document which is currently displayed.
The problem is that the PDF is ALWAYS taking the 'front' position, so any elements dynamically created appear behind it. This was a common problem with Flash back in the days of DHTML, and here we are again.
Is this the kind of behavior to expect from PDF, or is there a way to override it? Thanks in advance for the help.
try "shimming" an iframe under the elements.