Bất cứ ai cũng có ý tưởng để giải quyết vấn đề "n mục còn lại" trên Internet Explorer?

Question

Trong ứng dụng ASP.Net của tôi, đó là javascript và jQuery nặng, nhưng cũng sử dụng các trang chính và các phần Ajax .Net, tôi luôn thấy trên thanh trạng thái của IE 6 (và đôi khi IE 7) thông báo "2 mục còn lại "hoặc" 15 mục còn lại ", tiếp theo là" tải somegraphicsfile.png | gif ". Thông báo này không bao giờ biến mất và có thể hoặc không thể ngăn một số chức năng của trang chạy (nó dường như chắc chắn sẽ bị hỏng, nhưng tôi không tích cực).

Tôi có thể khiến điều này xảy ra 99% thời gian bằng cách chỉ làm mới độ tuổi .aspx, nhưng số lượng mục và đôi khi, tệp mà nó đề cập khác nhau. Thông thường, nó là 2, 3, 12, 13 hoặc 15.

Tôi đã tìm kiếm câu trả lời cho Googled và có một số đề xuất hoặc giải thích. Một số người trong số họ đã không làm việc cho chúng tôi, và những người khác không thực tế để chúng tôi thực hiện hoặc thử.

Dưới đây là một số ý tưởng/lý thuyết:

• IE không được bộ nhớ đệm hình ảnh đúng, vì vậy nó lặp đi lặp lại yêu cầu cùng một hình ảnh nếu hình ảnh được lặp đi lặp lại trên trang và máy chủ giả định rằng nó nên được lưu vào bộ nhớ cache cục bộ vì nó đã được phân phát trong ngữ cảnh trang đó. IE hiển thị hình ảnh một cách chính xác, nhưng ngồi và đợi một phản hồi của máy chủ không bao giờ đến. Thông thường các tập tin nó nói nó đang chờ được lặp lại trên trang.

• Trang đang sử dụng đồ họa PNG có độ trong suốt. Quả thực nó là, nhưng họ là jQuery-UI Themeroller tạo ra đồ họa mà, theo jQuery-UI folks, là IE an toàn. Các thành phần jQuery-UI là những thứ duy nhất sử dụng PNG. Tất cả các tham chiếu PNG của chúng tôi đều nằm trong CSS, nếu có. Tôi đã thay đổi một số đồ họa từ PNG tới GIF, nhưng nó cũng giống như khả năng nói nó chờ đợi somegraphicsfile.png vì nó là dành cho somegraphicsfile.gif là

• hình ảnh đang được quy định tại CSS và/hoặc JavaScript nhưng trên những thứ hiện không được hiển thị (ví dụ: không có mục nào). Điều này có thể là đúng, nhưng nếu có, thì tôi sẽ nghĩ rằng tải trước hình ảnh sẽ hoạt động, nhưng cho đến nay, việc thêm trình tải trước không thực hiện bất kỳ điều gì tốt.

• Chính sách lưu bộ nhớ cache của IIS gây nhầm lẫn cho trình duyệt. Nếu điều này là đúng, nó chỉ là máy chủ của Microsoft SW gặp sự cố với trình duyệt của Microsoft (điều này không làm tôi ngạc nhiên chút nào). Thật không may, tôi không có nhiều quyền kiểm soát cấu hình IIS sẽ lưu trữ ứng dụng.

Có ai nhìn thấy điều này và tìm ra cách chống lại nó không? Đặc biệt trên các ứng dụng ASP.Net với jQuery và jQuery-UI?

CẬP NHẬT

Một điểm dữ liệu khác: trên ít nhất một trong các trang này, ngay ý kiến ​​ra jQuery-UI cài đặt phần datepicker gây ra vấn đề ra đi, nhưng tôi không nghĩ (hoặc ít ít nhất tôi không chắc chắn) nếu điều đó sửa tất cả các trang. Nếu nó "sửa" chúng, tôi sẽ phải hoán đổi các plug-in vì chức năng đó cần phải có. Dường như không có bất kỳ sự cố mở nào chống lại jQuery-UI trên IE6/7 hiện tại ...

CẬP NHẬT 2

Tôi đã kiểm tra các thiết lập IIS và "cho phép hết hạn nội dung" là không bộ vào bất kỳ thư mục của tôi. Bỏ chọn cài đặt đó là một đề xuất phổ biến để khắc phục vấn đề này.

Tôi có một trang khác, đơn giản hơn mà tôi có thể tạo lỗi liên tục. Tôi đang sử dụng tệp jQuery-UI 1.6rc6 (mặc dù tôi cũng đã thử jQuery-UI 1.7.1 với cùng kết quả). Vấn đề chỉ xảy ra khi tôi làm mới trang có chứa jQuery-UI Datepicker. Nếu tôi nhận xét thiết lập Datepicker, vấn đề sẽ biến mất. Dưới đây là một vài điều tôi nhận thấy khi tôi thực hiện việc này:

1. Trang này luôn cho biết "(1 mục còn lại) Tải xuống ảnh http: ///images/Calendar_scheduleHS.gif", nhưng chỉ khi tải lại.
2. Khi tôi nhìn vào ghi nhật ký HTTP, tôi thấy rằng nó yêu cầu hình ảnh đó từ máy chủ mỗi khi được bật động, không tính đến bộ nhớ đệm.
3. Tất cả các yêu cầu cho hình ảnh đó đều hoàn chỉnh và trả về đồ họa chính xác. Không có mã nào được đánh dấu là 200 hoặc 304 (chỉ ra rằng máy chủ đang yêu cầu IE sử dụng phiên bản được lưu trong bộ nhớ cache). Tại sao nó nói chờ đợi trên đồ họa đó khi tất cả các yêu cầu đã hoàn thành tôi không có ý tưởng.
4. Có một hình ảnh khác trên trang (một trong các tệp giao diện người dùng PNG) có mã 304 (Không được sửa đổi). Trên một trang khác mà tôi quản lý để ghi lưu lượng truy cập HTTP với "2 mục còn lại", hai tệp đồ họa khác nhau (cả PNG giao diện người dùng) cũng có 304 (nhưng không phải là tệp được liệt kê là "Đang tải xuống".
5. Lỗi này không phải là vô hại - trang không đáp ứng đầy đủ Ví dụ: nếu tôi nhấp vào một trong các nút cần thực hiện tác vụ phía máy khách, trang sẽ làm mới.
6. Tôi đã di chuyển tập lệnh và tham chiếu tập lệnh đến cuối nội dung và điều này không ảnh hưởng đến vấn đề này. Kịch bản vẫn đang chạy trong $ (document) .ready() mặc dù (quá lông để phân chia trừ khi Tôi hoàn toàn phải).

CẬP NHẬT CUỐI CÙNG VÀ ĐÁP

Đã có rất nhiều câu trả lời tốt và gợi ý dưới đây, nhưng không ai trong số họ là chính xác vấn đề của chúng tôi. Cái gần nhất (và cái dẫn tôi đến giải pháp) là một JavaScript dài chạy, vì vậy tôi đã trao tiền thưởng ở đó (tôi đoán mình có thể tự trả lời, nhưng tôi muốn thưởng cho thông tin dẫn đến giải pháp) .

Đây là giải pháp của chúng tôi: Chúng tôi đã có nhiều trình tạo ngày jQueryUI được tạo trên sự kiện $ (tài liệu) .ready trong tập lệnh được bao gồm từ trang chủ ASP.Net. Trên trang máy khách này, một sự kiện $ (document) .ready của tập lệnh cục bộ có kịch bản đã phá hủy các trình đặt chỗ theo các điều kiện nhất định. Chúng tôi đã phải sử dụng "phá hủy" bởi vì phiên bản trước của datepicker đã có một vấn đề với "vô hiệu hóa". Khi chúng tôi nâng cấp lên phiên bản mới nhất của giao diện người dùng jQuery (1.7.1) và thay thế "phá hủy" với "vô hiệu hóa" cho trình duyệt ngày, sự cố đã biến mất (hoặc hầu hết đã biến mất - nếu bạn làm việc quá nhanh trong khi trang đang tải, vẫn có thể nhận trạng thái "n mục còn lại").

Lý thuyết của tôi như những gì đã xảy ra đi như thế này:

1. Nội dung tải trang và có 12 hoặc nên hộp văn bản với datepicker lớp.
2. Tập lệnh trang chính tạo trình đặt ngày trên các hộp văn bản đó.
3. IE xếp hàng các yêu cầu cho từng hình ảnh lịch độc lập vì IE không biết cách làm thế nào để lưu trữ đúng hình ảnh động yêu cầu.
4. Trước khi yêu cầu được xử lý, tập lệnh khu vực khách hàng hủy các trình đặt chỗ trước đó để đồ họa không còn cần thiết nữa.
5. IE còn lại với một số số yêu cầu mồ côi rằng nó không biết phải làm gì với.

Answer 1

Tôi đã gặp phải sự cố tương tự trước đó và đó là do đoạn JS đang chạy ở giữa trang, trình duyệt đang chờ nó hoàn thành thực thi trước khi hoàn tất tải xuống các tệp bổ sung cho trang web.

Tôi không chắc đây có phải là vấn đề cho bạn hay không, nhưng nó đã tự biểu hiện theo cách tương tự.

Answer 2

Liên quan đến hình ảnh bộ nhớ đệm, tôi đã phải sử dụng trình xử lý HTTP để đưa hình ảnh vào bộ nhớ cache chính xác. Cụ thể, có một hình ảnh mũi tên trong menu CSS sẽ gây ra hành vi chính xác mà bạn đang xử lý vì nó được sử dụng nhiều lần trong mỗi menu.

Đây là mã cho xử lý: http://www.groovybits.com/SrcViewer.aspx?inspect=~/PersistantImage.ashx

Bạn sử dụng nó bằng cách thêm một AppSetting trong web.config:

<add key="UniqueImageName" value="~/Images/image_name.gif"/> 

Và tham khảo các nguồn của mỗi hình ảnh bằng cách sử dụng bộ xử lý thay vì đường dẫn đến hình ảnh của chính nó:

~/Handlers/PersistantImage.ashx?key=UniqueImageName 

Answer 3

NẾU bạn sử dụng các hành vi ANYWHERE trong mã của bạn (hoặc thư viện bạn sử dụng sử dụng thứ em), ví dụ:

<style> 
    body * { 
    behavior:url(anyfile.htc); 
    } 
</style> 

Tiếp theo là NO giải pháp mà tôi biết và những bug report filed in IE Feedback on Connect cho IE8 (và IE7) đã bị từ chối cho cả phiên bản với báo cáo kết quả đóng hộp chăn sau:

này là một lỗi đã biết trong IE và cũng xảy ra trong các phiên bản IE trước đó. Lý do mà bạn thấy hàng trăm yêu cầu trong thanh trạng thái là vì IE xem xét để đọc tệp htc từ đĩa hơn và hơn nữa cho mỗi phần tử trên trang. Thật không may, tại thời điểm này chúng tôi không có kế hoạch sửa lỗi này. Chúng tôi sẽ xem xét điều này trong phiên bản tương lai của IE.

Trân trọng, Nhóm IE

Do đây là câu trả lời tương tự nhận được cho sự phát triển IE7 tôi sẽ không giữ hơi thở của tôi trên BAO GIỜ có này cố định.

Cập nhật:

Một suy nghĩ bổ sung dựa trên ghi chép cập nhật của bạn. Nếu trang không hoàn toàn phản hồi, như thể trang vẫn đang tải nội dung nào đó, hãy kiểm tra nội dung DOM được hiển thị cho bất kỳ cuộc gọi nào đến document.write() {bạn có thể chưa thêm chúng, nhưng lib có thể có}.

Nếu chúng tồn tại, hãy thử thêm câu lệnh document.close(); sau khi hoàn tất, điều này sẽ cho trình duyệt biết bạn đã hoàn tất việc hiển thị.

PS ở đây là liên kết bạn có thể lưu dưới dạng dấu trang (nhấp chuột phải vào "Thêm vào mục yêu thích ...") sẽ hiển thị cho bạn DOM được tạo khi IE thấy nó (một dấu trích dẫn xấu xí = CaMelCaSeMeSS) thực hiện tìm kiếm kết quả tìm thấy bất kỳ mã kỳ quặc nào có thể gây ra sự cố.

IE Tạo Nguồn: (thêm này làm vị trí cho bất kỳ dấu, biên tập viên sẽ không cho phép tôi liên kết nó lên)

javascript:'<xmp>'+window.document.body.parentNode.outerHTML+'</xmp>'; 

Answer 4

Nó là để làm với các "sửa chữa" cho PNG trong suốt trong IE .

Tôi đã gặp sự cố tương tự này với trang web đang hoạt động và không sớm tìm thấy giải pháp hợp lệ nào khắc phục cả vấn đề này và hình ảnh PNG trong suốt.

Answer 5

Tôi đã sử dụng this trong quá khứ với thành công lớn. Bạn cũng có thể kiểm tra this bài đăng trên blog.

Answer 6

Anh chàng này có một số great writeup on IE6 caching problems nhưng blog dường như không hoạt động.

Ông luộc vấn đề thành hai phần:

1. IE6 background-image flicker
2. Một IE lỗi/Tính năng: Internet Explorer Cache Is Not Used When You Run innerHTML Code to Insert the Same Image Multiple Times. Microsoft đề xuất hai cách giải quyết rất tồi (và trong trường hợp của tôi, chúng thậm chí không hoạt động), nhưng bạn cũng có thể giải quyết vấn đề này bằng cách đảm bảo rằng bạn không chèn các thẻ <img> qua innerHTML.

Giải pháp tự nhiên cho vấn đề # 2 là sử dụng background-image thay vì <img> thẻ; một cách vô lý, điều này sẽ buộc bạn phải vào vấn đề # 1; kết quả là, bạn có thể đánh bại vấn đề # 2, không tin rằng bạn đang không tiến bộ.

Trong trường hợp của tôi, tôi giải quyết cả hai vấn đề cùng một lúc, khi tôi thay innerHTML<img> thẻ của tôi với <div> thẻ mà có background-imagevà sử dụng document.execCommand("BackgroundImageCache", false, true) để sửa chữa nhấp nháy.

Answer 7

Tôi đã tìm thấy giải pháp cho hầu hết các dự án của mình.

Tôi đang sử dụng Plugin jQuery Fancybox hầu như trong mọi dự án.Nếu bạn đang sử dụng Fancybox và có "x mục còn lại" vấn đề thì đây là giải pháp:

Trong tệp css của fancybox gần cuối tệp có bộ lọc IE cho png bán trong suốt để tải đúng cách. Một cái gì đó như thế này:

.fancybox-ie6 #fancybox-close { background: transparent; 
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader 
(src='fancybox/fancy_close.png', sizingMethod='scale'); } 

Như bạn có thể nhận thấy đường dẫn trong thuộc tính src là sai.

Chỉ sửa đường dẫn cho tất cả các bộ lọc (có khoảng 20 bộ lọc) và sự cố sẽ được giải quyết!

Tôi khuyên bạn nên đặt một đường dẫn tương đối đến thư mục gốc, như thế này:

.fancybox-ie6 #fancybox-close { background: transparent; 
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader 
(src='/css/fancybox/fancy_close.png', sizingMethod='scale'); } 

Answer 8

Tôi đã cố định này bằng cách thực hiện những điều sau đây. Đó là một hack nhưng nó hoạt động.

Chỉ cần tải hình ảnh của bạn bằng cách sử dụng thẻ IMG vô hình ngay sau thẻ body. Ví dụ:

<body> 
    <img src="problem_image_here.jpg" style="display:none"> 

    ... 
</body> 

IE có vẻ như tải cùng một hình ảnh qua css mà không gặp vấn đề gì sau này.