先廢話一下

之前在自己的個人公眾號中提到了一篇利用 CSS 的方式進行 XSS 攻擊，當時有朋友跟我說，讓我去獲取那個網(wǎng)站的 cookie，再然后進入那個網(wǎng)站的后臺去玩。然而，技術(shù)能力實在有限，搞不了這些東西，只是覺得那個網(wǎng)站沒有適當過濾 HTML 標簽是一件很危險的事情。

不過今天要說的 CSS 代碼真的是讓 app 崩潰了，至于信不信，看圖就知道咯。

故事背景

昨晚在被窩中的我突然收到一封郵件，大概內(nèi)容是說因為 CSS 的問題讓 app 掛了。當時在想，怎么樣的 CSS 如此牛逼，居然讓 app 掛了！于是掏出手機按照郵件中提示的 URL 打開看了一下，我只想說，這代碼，額，算了，還是不吐槽了，其實要是我寫的話，肯定會更爛。

雖然是來自其他部門的一個頁面，但作為公司的一員，怎么能不為公司的產(chǎn)品考慮呢。聽起來感覺像是在拍馬屁，其實真的是，因為我最好奇的是出現(xiàn) bug 的原因是什么，當然，肯定也是關(guān)心產(chǎn)品的啦。

于是第二天一早就到公司開始排雷……

大概的過程

首先我仔細看了一下代碼，從最初懷疑是 animation 的性能影響低端設(shè)備運行開始排查。結(jié)果發(fā)現(xiàn)這個所謂的性能問題其實也并沒那么厲害，一時也找不到頭緒，然后源文件又不是在我們自己這邊，只好打開花瓶抓 CSS 文件，然后替換后，用刪除法一點點查。

最后在儲大師的提點以及提供的一個 URL 來看，居然是 rem 導致的。

https://bugs.chromium.org/p/chromium/issues/detail?id=364222

這個網(wǎng)址大家應(yīng)該都知道，是專門看 bug 的，當然，也可以提 bug 啦。

@-webkit-keyframes crashChrome { 
        0%{ -webkit-transform: translateX(0rem);} 
} 
.anim:before{ 
    content: ""; 
    width: 3rem; 
    height: 3rem;     
    border-radius: 3rem;     
    position: absolute;     
    left:5rem;     
    top: 5rem;         
    background-color: #06839f;         
    -webkit-animation: crashChrome; 
} 

<div class="anim"></div> 

剛開始看到這段 CSS 代碼的時候，我在想啊，這個好像也沒什么問題啊，不就是通過 :before 這個偽元素來做一個 animation動畫效果么，然后使用了 rem 這個單位量。

反正是百思不得其解。

還是找測試機，繼續(xù)刪除那個有問題的頁面代碼吧。先是用了三星的，發(fā)現(xiàn)沒問題，接著用了小米的，果然奔潰了?？戳艘幌掳姹荆堑氖?Android 4.4.2，小米的是 Android 4.4.4，難道是版本的關(guān)系？

總之，在最開始那塊有動畫效果的部分排查了很久都沒找到問題。最后還是回到那個已經(jīng)報了 bug 的頁面上看具體說明。

突然想到，這個頁面中用了 :before 來做動畫，莫非我們的這個頁面中也有，于是一搜，結(jié)果，真的有！

趕緊我們自己頁面上的這段代碼拿過來做嘗試，終于找到你了。趕緊回郵件告訴對方……

再次感謝儲大師的提點，讓我有機會了解到未曾了解到的一個問題。

簡單分析

這個 bug 在目前桌面端的設(shè)備中已經(jīng)被處理掉了，按照 bug list 頁面上說的，當時發(fā)現(xiàn)這個 bug 是在

Chrome Version: 34.0.1847.116 (Official Build 260972) m

這個版本上的，并且各系統(tǒng)都有。然而，現(xiàn)在的 Chrome 都已經(jīng)是 50 以上的版本了，所以桌面端完全不需要去擔心了。

但是這次既然是在移動端上遇見了，而且是 Android 4.4.4 這個版本，雖然是在小米3 中發(fā)現(xiàn)，但 Android 4.4.4 這個版本應(yīng)該還算是比較普遍的，難道真的會是這個問題。

獲取一下這個 webview 的 UA 信息，看到其中有一個是 Chrome/33.0.0.0 Mobile Safari，于是我想啊，可能應(yīng)該就是這個 webview 的關(guān)系了，畢竟我在小米3 這臺測試機上的各個瀏覽器里都看了一遍，沒發(fā)現(xiàn)問題。

嘗試了解

現(xiàn)在是知道 rem 和 animation 一起的時候回出現(xiàn)這個 bug，但是在其他元素中并沒有問題啊。出于自己的好奇心，于是又換了幾個方式來嘗試。

animation 換 transition

把 animation 換成 transition，并且也是通過改變有 rem 的屬性，結(jié)果發(fā)現(xiàn)這個想法的結(jié)果是，沒有任何問題。

放棄這個想法……

:before 是偽元素

想到 :before 是偽元素，那么對于偽元素的選擇符還有幾個，都嘗試一下看看。

注：這個截圖是曾經(jīng)個人整理的有關(guān) CSS 選擇符的一張圖

結(jié)果發(fā)現(xiàn)這四個偽元素選擇符全部都會讓頁面崩潰……

小結(jié)一下

瀏覽器（webview）的底層渲染機制我不懂，但就目前來看，可能應(yīng)該就是因為 Chrome/33.0.0.0 Mobile Safari 這個版本的問題，如果在偽元素中使用 animation，并且改變了其中的 rem 的值就會出現(xiàn)頁面崩潰的問題。

所以，可能應(yīng)該就是這樣：

• 使用了 :before 等偽元素中的其中一個來做 animation 動畫；
• 在 animation 動畫改變了其中的某個 rem 的值；

在這樣的前提下，又是使用有這個 bug 的版本瀏覽器，那么就會讓頁面崩潰。

如果要避免這個 bug 的出現(xiàn)，那么應(yīng)該是：

• 換一個 webview，高版本的應(yīng)該會好一些；
• 在偽元素中使用 animation 動畫時，不用 rem 單位；

不過好像現(xiàn)在大家都會去用 rem 單位，然后也會去用 animation 做動畫，那這樣好了，不在偽元素上使用者兩樣東西咯。

題外話

說到在偽元素上使用動畫，我想起了幾年前自己在做國際網(wǎng)站的時候，當時好像用的比較多的是 Firefox，然后在往返程的一個模塊中，就是用了偽元素的方式。

不過當時我好像使用的是 transition，并且當時主要是考慮 Firefox，所以也沒遇到什么問題。印象中遇到的問題就是，好像在某個瀏覽器中并沒看到那個 transition 效果，而且這個只是作為一個小“亮點”的存在，產(chǎn)品經(jīng)理也沒砍我。想想也算萬幸的……

哦，還有，如果各位已經(jīng)知道了這個 bug，也請不要嘲笑我，我真的是第一次知道，平時日常中很少這樣去寫樣式。-_”