As a front-end developer, business often involves some mobile H5 demand page development. However, after developing Web pages for a long time, it is inevitable to encounter some problems when switching to H5 page development.
The author presents the problems he encountered in the form of notes as the content of this article to readers, hoping to help every reader to a certain extent.
1. After the element is clicked/long-pressed, the :hover style always exists.
When an element is clicked or long-pressed in the mobile H5 environment (such as: material-ui Button), the style of the element’s :hover pseudo-class selector is always applied, which affects the element The default style.
In principle, elements in the H5 environment do not need to set :hover style interaction, but to avoid comparison, there will be a component element that adapts to both Web and H5.
The solution can be: use the attribute weight of the element itself higher than the attribute weight set in :hover.
2. The background shadow flickers
when some H5 elements are clicked. When the test classmate mentioned a bug to you, it said that the background flickered after clicking a certain element on the H5 page. This is because you set the cursor: pointer here. The solution is to set: -webkit-tap-highlight-color: transparent; cancel interactive highlighting.
Judging from this attribute, it has compatibility issues. In fact, in principle, H5 applications do not need to set a cursor. The best solution is to set cursor: default; to cancel the pointer interaction.
3. The iOS browser navigates back, and the page is not reloaded.
On the iOS side (such as: Safari browser), after going from page A to page B, use the browser navigation back button. After returning to page A, you will find that page A has no Reload, including data requests.
For example, to implement a payment function, the payment is completed on the B page, and after returning to the A page, it is expected to re-request the data to update the payment status. Everything works fine for Android (some Androids may have similar issues), but iOS will not be implemented as expected.
Reason for analysis: This is a caching mechanism of the browser's "back-forward cache (bfcache)" feature, which is used to speed up the user's speed when clicking the browser's forward or back button. bfcache saves the state of DOM and JS when leaving the page, that is to say, saves the entire page and puts it in the page cache.
Solution: The onpageshow event will be triggered every time a page is loaded (whether the page comes from bfcache or not), combined with the persisted property of the PageTransitionEvent object to determine whether the page is read from the cache.
// After the iOS browser backs the page, it will never read the cache snapshot problem
window.onpageshow = function (e) { if (e.persisted) { // If the page is read from the cache, refresh the page location.reload(); } }
4. Android browser navigation will return, ajax seems to be requested, but it has not actually gone to the background.
On Android mobile browsers, after going from page A to page B, use the browser navigation back button, and after returning to page A, The difference with iOS is: the page is reloaded, and the interface request defined during mount will be executed.
However, the data delivered by the interface is old, not the latest data after the operation on page B.
After contacting the students in the background to check the API interface log, I found that the ajax seemed to initiate the request in the front-end browser, but it actually did not enter the background.
After query analysis, it is found that in some browsers, in order to reduce repeated requests, ajax will cache the loaded data. When the request url does not change, it will directly read the data in the cache and will not actually request to the background. .
So we need to disable this caching feature and provide two ways to solve it:
Add anyAjaxObj.setRequestHeader("Cache-Control", "no-cache") before the ajax request;
add a timestamp after the URL: "?random=" + Date.now().