I'm displaying mathematical expressions in a webview (using jqmath library and some CSS). One requirement is that expressions should be centred, and here's what I use to achieve that:
<html><head><style type='text/css'>html,body {margin: 0;padding: 0;width: 100%;height: 100%;}html {display: table;}body {display: table-cell;vertical-align: middle;text-align: center;}</style></head><body><p>here goes the expression</p></body></html>
Since rendering math takes some time, the webview is hidden while the expression is rendering, and displayed only when it is ready (once the WebViewClient's onPageFinished has been called). This worked well until Android 4.4.
The problem with the new webview seems to be that it only applies CSS when it is visible on screen. So after revealing the hidden webview, the expression first appears in the top left corner, and only after ~0.1 seconds "jumps" to the center. This looks ugly, since I have to display many expressions in quick succession.
A related problem is described in this question: width:100% in CSS not rendering well in Android 4.4. The asker was able to solve his problem by removing the display: table; from html, but that doesn't work in my case.
So is there a way to either:
(a) force the new (Chromium-based) webview to render content while it is not visible, or
(b) display the content at the center from the beginning (without first displaying it in the top left corner).
It is not true that the KK WebView applies CSS only when visible on screen:
the WebView will not size itself if it has visibility set to GONE because the Android framework will call layout-related methods on it (like layout and onSizeChanged). This might be what you're seeing. Try setting the visibility to INVISIBLE instead.
WebViewClient.onPageFinished is not a reliable trigger for showing your WebView. What the callback really means is that the resource for the main frame had been loaded from the network. Unfortunately there never was a reliable callback that would tell you 'your content is ready to be displayed' - what you're describing probably happened to work because of particular timing. The most reliable way to not show unfinished content would be to do so in the HTML/CSS.
you might be using WebView.loadDataWithBaseUrl to load your contents into a new/blank WebView - this API is has an effect similar to re-writing the page's content (rather than issuing a 'real' navigation) and can result in weird layout. If possible use loadData or loadUrl. If neither of those are feasible try calling loadUrl("data:text/html,<body style=\"margin: 0px;\"/>"); before loading the real content (wait at least till you get an WebViewClient.onPageStarted callback for that bootstrap URL).
you might be setting height to WRAP_CONTENTS. This is very unlikely to cause the issues you're describing, but it would be good to rule out. Try setting a width of MATCH_PARENT and a height with a fixed number of pixels.
Related
Here is the desired outcome I'm looking to achieve by scrolling using react-scroll-parallax.
On Mobile browser
View web browser example here
Description
I want to create a website with the parallax affect shown above. The key elements being a website build in react containing three pages.
While scrolling from Page 1 to Page 2 I want the mobile device mock to start halfway on the screen (as to avoid the other content of page 1), then move to being basically centered.
While scrolling from Page 2 to Page 3, the website and components stick and once again act like a normal website scroll.
Additionally, during the scroll from Page 1 to Page 2, I want the content inside the device mock to scroll as well.
What I tried
For starters I was able to get nearly the affect I wanted by using a div with it's z-index and absolute position set, and parallax on translateY of -50, 125.
<div className={"absolute z-10 w-full"}>
<Parallax translateY={[-50, 125]}></Parallax>
</div>
The problem became however when I wanted to place content inside the div. Having another div within the parallax that also had z-index set seemed to mess with the parallax affect.
Important notes
Content inside device mock
One issue I found that was tricky was trying to place the content inside the device mock. I want a parallax both on the device mock itself, and the content within it.
I'm not entirely sure how I should crop the content inside the device mock.
The device mock svg frame and device mock mask can be found here if you want to give it a try
Device mock svg and mask
I tried imgs with various z-indexes, masking the div with an svg mask, using image backgrounds. Nothing is quite getting the preferred outcome.
Scaling of device mock
I want to make sure this works well on both mobile and browser. With that said I was trying to use margins to scale the device mock but I had a hard time with trying to then correctly get the mask to work for the content within the mock.
I'm not sure if using dedicated width and height sizes would be the ideal way to go, but very open to suggestions! It seems hard to scale the device frame and the mask properly.
Parallax of device and parallax of device content
I want the content inside the device mock to be html so that I can change it more than just an image. That being said the most important feature I want is for both the device and the content inside to have a parallax scroll affect.
Summary
I know this is a bit much for a quick simple stack overflow issue, but I've been trying a lot to get this to work and just can't seem to nail down the little details correctly. I sincerely appreciate all help and suggestions and if there is anything else I can provide please let me know!
The trickier part of the request was blowing up the <svg>, adding new <path /> and <clipPath /> for the color swap inside the phone mock.
Eventually I got it working here. The part linking the clipPath transition to the scroll progress looks like this:
const [y, setY] = React.useState(1739);
const onProgressChange = React.useCallback(
(a) =>
setY(Math.max(Math.min(1739, 1739 - ((a - 0.24) / 0.0018) * 17), 36)),
[setY]
);
const { ref } = useParallax({
translateY: [0, 185],
onProgressChange
});
The 1739 and 36 are max and min values for the translation and they are strictly related to the svg's viewBox. The other values allow tweaking the start, end and speed of animation, with regards to overall scroll progress.
This, together with some CSS, took care of binding the right animations to the correct scroll progress.
Feel free to tweak it some more, especially if you add more markup.
The other thing I wanted was a function activated shortly after scrolling, which would snap the scroll to certain positions. Namely, to the .page elements.
I used gsap's ScrollTrigger plugin for the task, for multiple reasons:
I'm somewhat familiar with it (used it before)
it's performant, light and non-obtrusive (basically quits when it detects another user scroll)
listens to all relevant events (touch, mouse pointer, keyboard) without me having to make sense of them, providing a unified interface.
uses inertia (if you scroll down faster from page 1 it will scroll past page 2, directly to page 3 - other scroll plugins limit you to having to scroll once for each page change)
works well on mobile devices
There are other libs/plugins out there for the task, you don't have to use gsap (although I do think it's awesome). If you end up including it in your project, make sure you comply with their licensing (which is not MIT).
By the way, my first choice for the parallax effect per-se would also be gsap, as their timelines provide a lot of flexibility and options.
Their most advanced stuff is reserved for subscribers, but even if you limit yourself to the free plugins, you're still getting more than from alternative libs/plugins, IMHO.
See it working.
I'm trying to find the reason for performance problems on a mobile website (based on React and Material UI).
The page shows fairly complex content (a form), which however does not change (in respect to this question). The form itself has position: fixed, exact coordinates and even transform: translateZ(0).
Visually on top of the content there is a 48x48 pixel 100% rounded <div> (a custom FAB = Floating Action Button) that is scaled up to 25x during a transition (covering the whole screen when finished).
The FAB is basically an overlay for the whole page. It's an element outside of the form tree.
When I simplify the page by removing the complex form, the FAB animated smoothly even on low-end hardware (thanks to the GPU).
However, with the form the performance decreases significantly.
I see no reason for that and would expect that the form would get it's own layer and only rendered ("painted") once.
When looking at the Chrome DevTools timeline with just the Paint option checked I see that a lot of form elements (like a simple label) get re-painted during the animation.
See the images below for the reasons that Chrome gives for that:
I don't really understand what that means. Why chooses Chrome to repaint these elements?
Update 1
I was able to reproduce the problem here: http://www.webpackbin.com/N18obvEBM
The problems show up when there is a MUI <Drawer>. Even when it is closed (moved out of the viewport using transform: translate) it forces the browser to re-render:
It's even worse if the Drawer is visible on screen.
Note that apparently it makes a difference if the browser window is on a HiDPI (4K) screen or not. Same test on a 1050p screen:
On the lower-res screen the circle is apparently scaled-up from the 48x48px raster rendering (edges become very blurry). That does not happen on the HiDPI screen.
Anyway adding display:none to the Drawer layer makes makes the rendering perform well (but is obviously no solution).
I have a site that I'm working that has navigation bar with secondary block-level elements (images in my case) inside the <a> tags which respond to the window size by either floating or not floating. As long as a user never resizes their browser window after loading the page, the issue would never occur, but it appears as though if the page is stretched wide, and then scaled down without reloading the page, the float style attached to the main CSS declaration (not inside a #media query) fails to activate.
http://jsfiddle.net/MrPickle/ace1rtrq/
Here's an example the behavior that I'm seeing (with the same css code I'm using for layout). If you play with the size of the result panel, you can see what I'm talking about.
I know that I could use javascript to monitor the width of the page and add or remove a .left class to the inner element as needed, but I don't think that's the most elegant solution possible. Has anyone ever run into this kind of an issue?
Facebook Connect uses JS/CSS overlays/popups for user interaction. I have sites with Flash elements, and no matter how I set the z-indices, the Flash always seems to go to the top.
I have a similar and likely related problem with a div with display:fixed at the top of the screen, where it gets covered by the Flash when you start scrolling.
How can I make sure the Flash element layers properly?
If you just need your flash to fall behind other object then you should use wmode=opaque. This will correct the z-index.
wmode=transparent will also correct the z-index but it also makes your stage transparent so whenever you have nothing on the stage or gaps between objects your html will show through underneath. This in turn causes more system strain.
Ergo if you just need the z-index correcting use wmode=opaque
Generally, I've needed to set the wmode=transparent property on the Flash object and/or embed string.
http://www.communitymx.com/content/article.cfm?cid=e5141
I have a simple Flex application that is a panel with a repeater inside of it; albeit a little simplified, it is like such:
<mx:Panel id="pnl">
<mx:Repeater id="rp">
<mx:Label text = "foo" />
</mx:Repeater>
</mx:Panel>
I am then embedding this Flex application into an HTML wrapper. I am then attempting to dynamically re size the embedded Flash object in the HTML as the Flex panel changes size (thus allowing the Flex application to consume as much of the HTML page as it needs).
I am doing this by doing the following actionscipt:
pnl.addEventListener(ResizeEvent.RESIZE,function(event:Event):void {
ExternalInterface.call("resize",event.target.height);
});
which in turn calls this javascript function:
function resize(height) {
// the embed or object that contains the flex app
var e = document.getElementById('flex_object');
if(e) e.height = height;
}
This seems to work perfect in IE, however I get strange results in Firefox / Safari, the repeater works for n number of times, and then the text seems to get cut off / disappear in the repeater, see the attached image:
alt text http://img528.imageshack.us/img528/9538/rpre0.jpg
Can anyone explain why this is happening, and if there are any workarounds / ways of doing the same thing?
I'm currently working in the same thing (a swf that dynamically changes it's height depending on the content it's currently holding). I also had a similar problem to yours trying to make a multi-line button.
I'm new to flex but I managed to solve the problem manually invoking the updateDisplayList() of the container... I think it "forces" a render somewhere... it's parameters are the width and height of some area where the changes happen. Sorry for not knowing the details... But it worked for me.
Why not simply using percent width and height on your HTML page for your Flash object ? This way you event don't have to do anything to resize your SWF...
That's very strange - it looks like Firefox/Safari are expanding the draw area of the embed, but somehow Flash is not getting the message that it needs to render the new pixels.
You could probably work around this by doing something to force Flash to update itself, but since the communication between the browsers and the embed seems to be confused it would probably be less hackish to take a different approach, that fits into the browsers' event flow without bugging.
For example, instead of resizing the embed, you might try putting Flash inside a DIV, setting the Flash's size to 100%, and then resizing the DIV. That seems a lot less likely to misbehave.
My experience is that Flex's resizing abilities are... funny. Sometimes they work the way one would expect, other times they do not. There are a couple of things you could try: first, trace the value you expect to get in Flex for the height or even ExternalInterface.call("alert",event.target.height); This will let you know if it is a JavaScript or a Flex problem for sure (but I suspect it is Flex).
Your problem might have to do with the scaling of the component:
Setting [the height] property causes a resize event to be dispatched. See the resize event for details on when this event is dispatched. If the component's scaleY property is not 100, the height of the component from its internal coordinates will not match. Thus a 100 pixel high component with a scaleY of 200 will take 100 pixels in the parent, but will internally think it is 50 pixels high.
If it is Flex and that does not help, I would try using callLater in front of the ExternalInterface call, often that will allow Flex enough time to figure out what the heck it is doing. Occasionally, setTimeout is needed, but I find that awkward.