I have a website that consists of a bunch of single-page-template jQuery Mobile pages that are linked to each other using prefetching and caching. All pages exist in the DOM (after they are prefetched).
This works fine on my desktop browser. However, when I browse my site using my HTC EVO 3D Android phone (either the default browser or the Opera browser), switching between pages acts like I'm actually going to an external page. In other words, the browser's address bar appears momentarily, then the page turns white, then the new page loads, then the address bar goes away.
I would expect the behavior to be exactly that of a multi-page-template. For example, if you browse the multi-page-template in the jQuery Mobile documentation, you can switch from one page to another very smoothly. The browser address toolbar does not pop up, and there is no white flickering in between pages. However, if you browse the "persistent toolbar" example (which uses prefetching to load all the pages in the example), you will see the same behavior that my site is experiencing. The browser's address bar will appear, the page will turn white, the next page will render, then the address bar will go away.
So how do I make my prefetched pages act like the multi-page template without having to rewrite my site to use the multi-page-template?
For reference, here are the jQuery Mobile persistent toolbar demo and multi-page demo that I believe should work exactly the same (in regard to URL address bar appearing):
http://jquerymobile.com/demos/1.3.0-rc.1/docs/toolbars/footer-persist-a.html
http://jquerymobile.com/demos/1.3.0-rc.1/docs/pages/multipage-template.html
Unless your initial page links directly to all of your other pages with the data-prefetch attribute on your <a> link tags, those pages will not be prefetched and cached. I state this because your question implies that there is some chaining with your pages which is not supported. You can load also load and cache them via the API.
$.mobile.loadPage( pageUrl, { showLoadMsg: false } );
Are you able to actually inspect the DOM on your mobile Android device?
Is there any chance the pages are being flushed from the DOM based on a memory constraint? I am not aware of any specifics in the jQM docs on this scenario but at some point you will fill the cache.
Related
I have page with few most used links, I want use it like my homepage and new tab page.
when I press ctrl + t for new tab I need see my page (it is done) but with empty address bar for faster writing in it (it is impossible for me).
.htaccess, javascript it doesn't matter. Any ideas? Thanks.
Your users do not expect that CTRL-T or ⌘-T will take them to a specific site or a page with a blank address bar, which is why browsers don't give you that capability. Unlike a native desktop application, you cannot control the workings of the user's browser. You should not even try.
I am developing a mobile web application using ASP.NET mvc 4. I am facing problem with response.redirect to some other website (eg: http://www.google.com) from my controller,it is showing "Error Loading Page" message without redirect.
I have tried the following codes to redirect under "About" action on Home controller:
return Redirect("http://www.google.com");
return RedirectResult("http://www.google.com");
response.Redirect("http://www.google.com");
All the above produced the same error.
Note: the hyperlinks in view pages are working fine
Thanks
When you are setting up your link to the controller...you need to make sure the data-ajax attribute is set to false.
Redirect
My understanding is that jQuery mobile wraps all anchor request in ajax, unless otherwise specified, and your response.redirect is just being served to the jQuery .done function which can't handle it properly.
http://jquerymobile.com/demos/1.2.0/docs/pages/page-navmodel.html
Important: rel="external" and $.mobile.ajaxEnabled=false
Slightly different implementations of the replaceState API in various
browsers can cause odd behavior in specific scenarios. For example,
some browser implementations (including desktop browsers) implement
the popstate event differently when linking externally and moving back
to a page onto which state has already been pushed/replaced. When
building a jQuery Mobile application where the Ajax navigation is
being explicitly disabled, either through the frequent use of
rel="external" on links or by disabling Ajax navigation completely via
the $.mobile.ajaxEnabled=false, we recommend disabling the pushState
feature to fall back to the hash based navigation for more consistent
behavior.
I suspect your problem is that you are redirecting outside local site.
See this part of the documentation: http://jquerymobile.com/test/docs/pages/page-navmodel.html
Hash values created by jQuery Mobile are normalized as full paths
relative to the URL of the first "real" page that was loaded.
Then later it confirms the "local" requirement here:
When a link is clicked, jQuery Mobile will make sure that the link is
referencing a local URL
I think the solution is to not redirect users to other domains.
UPDATE
The above solution highlights the wrong part of the problem but the solution may still be the same. You should use javascript to do the redirection such as:
window.location = 'http://www.google.com/';
I believe you will run into issues if your JQM solution is attempting to make an ajax call that is then redirecting. One issue, specifically for google.com, could be if you are signed in to google. It will then redirect you to https for example. That could be interfering with the JQM / window.location.hash.
I have a very simple test case that explains the problem.
Here's the page that I'm displaying in Rails in an ERB file.
<div><%=rand%></div>
<p>Go</p>
To show the error, I load the page. I note the random number displayed as rand1. I click on the Google link. I click the browser's "Back" button. I note the random number displayed as rand2.
Here's the problem:
In Firefox and Chrome, rand1 != rand2 (always).
In Safari and IE, rand1 == rand2 (always).
Why the discrepancy in browsers? Why is Safari and IE caching the output from Rails while the other two browsers are not? How do I get Safari and IE to refresh the page?
(This is a simple test case to show the problem - this has implications in my Backbone application).
IE and Safari appear to be caching the response from the server, obviously; as long as your browsers are configured correctly, you can change this by changing the Cache-Control header in the response.
Another Stack Overflow post shows the appropriate way to do that, though in Rails 3 there's a shortcut method to accomplish this: you can invoke expires_now in the controller action to avoid manually setting all these headers.
WebKit in particular has an aggressive page caching strategy for handling exactly the case you're describing (clicking a link and then immediately clicking the back button). The idea is to make the back action happen almost instantaneously by caching not just the resources but also the DOM and other state of the page. You can read about it in these two articles:
WebKit Page Cache I — The Basics
WebKit Page Cache II — The unload Event
You may be able to use a combination of the load/unload and pageshow/pagehide events to accomplish what you need.
I'm not sure if IE implements something similar to WebKit, but maybe this will fix it too.
I'm trying to write a Firefox extension that speeds up browsing page sequences by preloading sequence items, preprocessing them, and showing on request.
Is there any way to load and process DOM of arbitrary web page (on the same site as currently opened) in background from privileged extension code?
Ideally, the document's javascript should work as it would in a normal browser window. I suspect a hidden window would be required for this. The context on that javascript should not be privileged then.
Loading should allow user to continue normal browsing in all visible browser windows.
I don't like the idea of injecting iframes to currently opened document and making them optionally visible (the principle used by Webcomic reader userscript)
From the add-on SDK, the page-worker module might be close to what you need:
The page-worker module provides a way to create a permanent, invisible
page and access its DOM.
That said, I have no idea whether it's possible to load that invisible page into a (current or new) tab / window. You might be able to replace a current tab's document.body by the page-worker's one. Possibly. If it's legal.
You could use a lightweight browser extension to collect all links on a page onload and use link tags to prefetch the content for each, the browser will load those pages in the background: https://developer.mozilla.org/en/Link_prefetching_FAQ
OR
If you need to preload a page and have access to its DOM from extension land, you could use the Page Worker API from the Add-on SDK: https://addons.mozilla.org/en-US/developers/docs/sdk/1.0/packages/addon-kit/docs/page-worker.html
I believe so. assuming your javascript is already running
var doc = gBrowser.selectedBrowser.contentDocument;
will get your the document of the loaded tab, you can then process it and do with it what you want. Doing it in the background and keeping the app responsive is a different story :)
I've been seeing this on a few websites recently where a link has changed the href of the window.location, but the page does not reload when the link is clicked, and the page remains scrolled down by the amount it was before. Does anyone know how this is done?
The sites you're thinking about probably use the new HTML5 History API, which allows you to change the behaviour of the back buttons and the address bar. Here's a demo: http://html5demos.com/history
Note that most funny business with hyperlinks will confuse search engines. Make sure your site works acceptably in an ancient browser (Lynx comes to mind) and/or read up on Google's Ajax Crawling Guidelines.
If you want to change the URL in the browser address bar without reloading the page, do this
Change URL
stateObj = The stack in which the current state of the page will be pushed
"page2": This parameter is currently being ignored by the FF.
"newpage.html" : New URL which will be displayed in the address bar
reference: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history
Supported by: FF 4.0+, Chrome 8.0+, Safari 5.0+, Opera 11.5+, IPhone 4.2.5+