Alright so in the link below someone already described my issue that I am encountering.
https://developer.apple.com/forums/thread/699982
Basically means that on bookmarked pages on IOS 15, if you minimize the window. dropdownsoptions will become invisible.
now my client luckily accepts that is something I can not solve. But I was wondering if there are workarounds besides telling the users to close their bookmark after using the webapp. like is there a way to hard refresh the browser in such way after minimizing so the users don't have to close the webapp every time?
Have a look at the following site http://www.soe.gr.
The whole page has been built with CSS Page Builder Magic 2 (projectseven.com).
Every button is a link to a different .html page.
However, I do not know why every button press creates a flash effect in the page, the background changes instantly color and generally it gives an impression of abnormal operation. I have not met any site with such behavior except some pages inside projectseven site.
Do you have any idea why that happens? Is it something wrong with Page Builder Magic approach?
I am new to Web Development world and I want to know if there is any problem with these guys.
Thank you very much
I checked it out, it doesn't behave abnormally at all for all those effects you have there, I checked out the size of one of the images it is about 250kb, then imagine the other images which I assume are of the same size, and they are all going to be loaded when the page loads, you definitely should expect some effect
This seems rather a common problem, however I can't find any reliable sources on this.
Once in a while Chrome will display a stylesheet-less version of page for like 2-3 seconds and soon after the page is displayed correctly. It can affect the very same page once in every 20-50 refresh and its not tied to a specific site. Happens all over the place. There are some threads about this here and there, but I have yet to find a full explanation.
Is this a bug? Feature? Is there a way to prevent Chrome from behaving like this on the client or perhaps server side?
In my experience, this happens when the network connection is poor and the page is (necessarily) loading slowly. The page's HTML will render first, and other assets called for within that HTML (like stylesheets or images) are rendered only after their calls are complete and their respective files load.
I have noticed this as well. It's definitely a bug. It seems to be this issue:
http://code.google.com/p/chromium/issues/detail?id=75761
You can "force" the stylesheet to load by opening the inspector (ctrl+shift+i).
shift + f5 should reload the page and the referenced stylesheets
With a normal reload it will only reload the page itself, and incorrectly assume that the stylesheets in the cache (the ones that never loaded in the first place) are correct.
In my Flex app I give the user the ability to open up a new item form ( s:Panel ) and create multiple items on the page.
Sometimes for some odd reason bringing up the panel (simple task) seems to take a really long time to load (like 30 seconds or so) However, the weird thing is that if right after I click to open I navigate away from the Tab and back again to the Flex app tab it shows up right away.
I'm not sure if this has to do with refresh rate or some setting or is it general performance/memory issue with my app that I have to consider. When the application work it works fairly fast which is making me think it's not memory/performance issue.
It's hard to be sure without more details, but are you following the component life cycle? Just to be sure we're talking about the same thing, here's a nice presentation about it: http://www.slideshare.net/rjowen/adobe-flex-component-lifecycle-presentation
The following code was known to be working three weeks ago. In the interim we have installed IE 7 and a bunch of security patches. The ultimate question will be, does anyone know how to restore the old behavior?
Scenario
We have the following JavaScript code in web page 1 (let's call it foo.aspx), that is invoked on a button click:
window.open("http://Foo/App2/bar.aspx, "_blank", "titlebar,status,width=650,height=600");
The second web page (bar.aspx) is then supposed to open on top of foo.aspx. The user does some stuff, and when they click a button bar.aspx writes some values from bar.aspx back into fields on foo.aspx using JavaScript via window.opener.document, addressing each element individually and modifying its innerText. Then the user closes bar.aspx and there's foo.aspx where they left it, except now it has the values from bar.aspx in certain fields, and the user goes happily on their way using foo.aspx. This has been working for over two years.
During the last two weeks we've applied a bunch of security patches and upgraded to IE 7. Now the behavior is this:
If I am testing and simply navigate to foo.aspx directly, then upon clicking the button bar.aspx opens and then suddenly the focus switches back to foo.aspx with a popup dialog with "The webpage you are viewing is trying to close the window. Do you want to close this window? " If I choose "No", then foo.aspx stays alive, I have to Alt-Tab to get back to bar.aspx, and after that everything works as before. However, this is going to be a pain for the users. Note: NOWHERE IN foo.aspx NOR bar.aspx IS THERE A CALL TO THE close() METHOD!!! So I don't understand why the popup says what it says.
If I access foo.aspx via the application, which means it has been opened programmatically and not explicitly by the user, then bar.aspx opens and you can see foo.aspx disappear (close) behind it. Then bar.aspx gets JavaScript errors because the window.opener is no longer available.
Secenario #1 is non-optimal but at least would be a valid work around (if somewhat of a user training issue to train them to hit "No" and then Alt-Tab, where before none of this was happening. Scenario #2 is non-optimal in the extreme, given that the whole purpose of bar.aspx is to write those values back to foo.aspx.
Other things to note
Now that we've installed IE 7 and the subsequent Active Directory policy changes, the behavior is happening as described even on IE 6.
Both foo.aspx and bar.aspx run on the web server, on the same web site, but in different virtual directories. These are internal application accessible only from inside our network by authenticated users.
Having the server in Intranet zone (where it normally is) or in Trusted Sites makes no difference. I can see no settings in either Zone nor in Advanced Settings that would apply to this behavior, and both the Intranet and Trusted Sites zones are set to be extremely liberal in their policies, especially around script behavior.
I can make any changes I need to in bar.aspx and its client-side scripts, but am limited to only being able to change the button click JavaScript code in foo.aspx (that page is supplied by a vendor, whereas bar.aspx is internally developed).
I reiterate that other than the updates through window.opener.document, foo.aspx is not touched by bar.aspx, and certainly there is no attempt to invoke close() on it.
So, the question remains what in IE 7, or more likely in a security patch, would have broken this? We have a sister shop that is running the same code on IE 7 and they have not reported this issue. So it seems like it has to be something environmental, and right now I keep thinking it must be a patch that got applied. I would take a KB article, IE setting, registry hack, JavaScript change or anything else to fix this.
Thanks for any and all suggestions.
it might be a typo but there's a missing " after the bar.aspx in the sample code.
Opening a window programatically and setting the name to _blank, why are you doing that?
I'm not saying that has anything to do with your issue, but it's probably not a good idea.
It is odd, first thing I would do is fix up a couple strange things in the code so far.
Use an absolute path such as "/App2/bar.aspx" without the protocol or server name since the apps are on the same server.
You can't actually control the titlebar or status bar outside the intranet zone so remove those values from the options list.
Is the pop up blocker closing the pop up window?