本篇博文會不斷的收錄我在作H5頁面時遇到的問題以及解決方案,固然有的問題,我也沒有遇到好的解決方案,因此若是你有解決的辦法,請務必不吝賜教!javascript
H5開發中的故障css
在新版本的 Chrome下音頻或者是帶有聲音的視頻若是設置了自動播放,便會被瀏覽器視爲噪音而被屏蔽,解決的辦法很簡單,那就是爲 vidoe
或者是 audio
添加一個 muted
屬性一開始就爲靜音狀態,而後調用一個異步JS來將音量調整爲100。html
setTimeout(function(){ oVideo.volume=100 }, 100);
實際上 iframe
在移動端上的應用很是少,這裏要友情提示下:「能不用,就堅定不用」。這是由於在移動端瀏覽器上其 bug 太多,並且在低版本與高版本中的 Android或者是 IOS中也不盡相同。
本人由於須要在移動端上經過 iframe
來嵌套登陸註冊的需求,因此就遇到了一個活生生的教訓,「滾動條不出現,或者是不能滾動」。而且因爲手上可供測試的機型太少,因此我大體總結了 iframe
在移動端的出現問題的狀況:
首先,在低版本的 IOS或者是 Android上,給 iframe
設置 overflow:scroll
並不會出現滾動條,或者說根本就沒有滾動條。java
對於這種問題,咱們能夠經過爲被嵌套頁面(也就是iframe中的頁面)設置滾動條,從而在iframe中進行滾動來解決。
而在高版本的 IOS或者是 Android中已經能夠支持 iframe
出現滾動條,可是在 IOS中卻還有一個問題,那就是一旦 iframe
或者是其上級元素只要應用了position:fixed
定位就會致使滾動條失效。web
解決這一問題也很簡單,那就是在避免採用 position:fixed 定位,使用其它定位方式進行替代。
也或者能夠給iframe所在頁面定義以下樣式:chrome
body,html{width:100%;height:100%} iframe{width:100%;height:100%}
可是,若是你必需要使用 position:fixed
定位,而且還須要 iframe
出現滾動條這種過度的要求,實際上,也不是不能夠,在 webkit
的私有擴展中有這樣一個 CSS屬性:-webkit-overflow-scrolling
它用於控制所應用的元素是否具備滾動的回彈效果。它有兩個取值,默認值爲 auto
表示通常滾動效果,還有一個 touch
的取值,表示開啓回彈滾動效果。跨域
而 -webkit-overflow-scrolling
有一個特別的使用方式,利用它咱們就能夠實現想要的效果。首先爲 iframe
再包裹一層。瀏覽器
<div class="wrap"> <iframe frameborder="0"></iframe> </div>
而後爲這個包裹層應用 -webkit-overflow-scrolling:touch
屬性,而且這個包裹層必定要是 fixed
定位。緩存
.wrap{ position:fixed; width:100%; height:100%; left: 0; top: 0; -webkit-overflow-scrolling: touch; overflow-y:scroll; } iframe{ width: 100%; height: 100%; }
經過測試發現,這種實現方式雖然能夠兩者兼得,可是依然避免不了在低版本的IOS(估計在IOS8及如下)出現不能滾動的問題。所以實際使用時要作好取捨。安全
固然,若是你有更好,更完美的解決辦法,請與我聯繫!
該問題出如今 iphone7的微信上,當一個活動存在多個頁面,那麼若是進入第二個頁面時,再點擊微信 app上的返回按鈕,雖然能夠返回 history中的上一級頁面,可是會出現頁面內容沒有刷新仍是最後跳轉時的狀態。
解決方案很簡單,那就是每進入到一個頁面,都會去判斷這個頁面是不是從緩存中讀取的,若是是則強刷頁面。
實現這個功能,咱們能夠利用 window.onpageshow
事件的 pageTransitionEvent
對象來判斷當前頁面是否從緩存中讀取。
具體代碼:
let isIphone = /iPhone/.test(navigator.userAgent); if(isIphone){ window.onpageshow=function(event){ if(event.persisted){ location.reload(true); } } }
persisted
是 pageTransitionEvent
對象中的一個屬性,它的返回值是一個布爾值,用於表示頁面是否從緩存中讀取。 關於 onpageshow
事件的兼容性,能夠看下圖
pageshow
事件對應的還有一個 pagehide
事件,它們與咱們常見的 onload
, onunload
事件有很大的相同之處,都是頁面打開時就會觸發,可是不一樣的是,pageshow、pagehide
則在頁面被打開或者是關閉時觸發,而 onload
則是等待頁面資源加載好後纔會觸發,而且一旦頁面是從緩存中讀取時就不會觸發 onload
事件。
不管是PC端仍是移動端 ,「返回上一頁」功能總會有用到的時候,在PC端,咱們使用 history.go(-1)
就能夠返回上一頁,可是在移動端事情總會變的複雜些,例如用戶是經過掃碼或者是點擊app中分享的連接從而使用app內嵌的webview 來打開頁面,此時再使用 history.go(-1)
便會不許。
history.length //=> 1
由於上一頁的來源是一個二維碼或者是 App中的對話框。
解決這一問題能夠經過 document
的 referrer
屬性獲取來源的地址。若是來源地址是一個空,那麼咱們默認向活動集合的首頁跳轉。
if(document.referrer === ""){ $('.back-btn').attr('href','/'); }else{ $('.back-btn').attr('href',document.referrer); }
關於 referrer
須要注意如下幾種狀況會致使其值爲空,也就是沒法獲取上一級的來源頁面。
location.reload()
刷新(location.href或者 location.replace() 刷新有信息);rel="noreferrer"
(兼容IE7+);<meta content="never" name="referrer">
參照上述限制的因素,咱們能夠說referrer
不只能夠解決移動端的返回上一頁問題,反而它更適用於移動端。
下面是 referrer
兼容性狀況:
關於 referrer
它還有一個安全方面的應用,例如 CSDN 就是經過它判斷用戶進入資源的下載頁時是不是從該資源的主頁來的,而非是經過盜鏈的方式進來的。
咱們一般使用 微信的JSSDK時,都會根據後臺返回的簽名、時間戳、appid等參數直接注入權限,而且會直接將分享的內容在 wx.ready()
方法中進行初始化。
wx.ready(function(){ let share = { title:'', link:'', desc:'' }; wx.onMenuShareTimeline({ title: share.title, link: share.link, imgUrl: share.imgUrl, desc: share.desc, success: function() { shareAdd(); } }); })
那麼,若是分享的內容是動態改變的那該怎麼辦呢?
其實,很簡單隻要將 wx.ready()
中爲每一個分享方式進行處理的功能,按照本身所須要的分享內容再跑一邊便可。
微信的JSSDK中,咱們經過爲每一種分享方式指定 link
屬性的值來決定分享出去的連接是什麼,可是在微信中有一個限制,那就是若是分享的連接與當前頁面的連接不在同一個域(即存在跨域的狀況)link
屬性指定的值將會失效,而且默認是當前頁面的連接。
解決這一問題,須要後臺的小夥伴協助了,可讓後臺的小夥伴在當前活動域名下創建一個新的接口,例如 share.html
,這個接口只有一個功能,那就是一旦訪問這個接口(頁面)就跳轉到咱們須要分享的那個地址。最後將這個分享的接口地址做爲 JSSDK 的 link
屬性的值。