Patch: set privacy.file_unique_origin w wersji 68 Firefoxa

[jwal2]

W wersji 68 Firefoxa przestała działać tworzona przeze mnie strona internetowa wywoływana lokalnie (file://). Strona ta działała we wszystkich poprzednich wersjach Firefoxa oraz dość poprawnie da się wywołać w innych przeglądarkach (Microsoft Edge, Opera, Chrome). Dokładniej, nie funkcjonuje przesyłanie linków do dwóch ramek jednocześnie za pomocą JavaScriptu. Poniżej fragment kodu:

Plik: index.html
...
<frameset cols="240, *" id="zestaw">
<frame src="thumb.html" name="frame1" Id="frame1" frameborder="0" marginwidth="0">
<frameset rows="*, 20">
<frame src="" name="frame3" id="frame3" frameborder="0" marginwidth="0" marginheight="0">
<frame src="" name="frame4" id="frame4" frameborder="0" marginwidth="0" marginheight="0">
</frameset>
</frameset>
....

Plik: thumb.html
...
function dodwoch(obrazek,podpis){
parent.frame3.location.href = "original/" + obrazek;
parent.frame4.location.href = podpis;
}
...
body
...
<a href="javascript:dodwoch('01-P1010651.JPG','original/01-P1010651.html');"><img ....></a>
...

Problem rozwiązuje wyłączenie patcha: set privacy.file_unique_origin=false.

Jeżeli jest błąd, to trzeba by go poprawić w następnej wersji. Jeżeli natomiast musi tak być ze względów bezpieczeństwa, to dobrze by było wprowadzić opcję do wyłączania tego patcha dla wskazanych plików strony internetowej przy wywołaniu lokalnym (file://).

Czy ktoś może poradzić, co z tym problemem dalej robić?

[krystian3w]

Kto w dzisiejszych czasach jeszcze sięga po html4 i ramki z niego?

[jwal2]

Sięgam po html4, bo stronę robię od dobrych kilku lat i służy ona do archiwizacji moich zdjęć rodzinnych. Zacząłem w tym standardzie, bo ramki doskonale się nadawały do prezentacji zdjęć (w jednej ramce jest menu, a w sąsiedniej wyświetla się obrazek, który automatycznie dostosowuje swoją wielkość do aktualnej wielkości ramki (można go ściskać, rozciągać i plusikiem powiększać w ramce do maksymalnych wymiarów...). Wybrałem Firefoxa, bo inne przeglądarki nie mają aż takiej funkcjonalności. Poza tym, miałem nadzieję, że twórcy tej przeglądarki będą stosować zasadę kompatybilności wstecz i do wersji 67 tak było. Moja strona nie jest na tyle elastyczna, żeby nadążać za zmieniającymi się standardami - wszelkie przeróbki związane są z modyfikowaniem setek plików HTML, a poza tym będę jej raczej używał tylko lokalnie. Oczywiście, mogę okresowo wyłączać patch, tylko jak to wytłumaczyć mojej babci, która o dziwo ma swojego latopa i chciałaby też od czasu do czasu zerknąć na te zdjęcia? Poza tym, aż się boję, co wymyślą twórcy Firefoxa w kolejnych aktualizacjach?

[dexter]

A mógłbyś pokazać błąd na działającym przykładzie na https://jsfiddle.net/ lub https://codepen.io/ ?

[jwal2]

Próbowałem wejść do proponowanych przez Ciebie portali, ale nie umiem ich obsługiwać. Przepraszam, ale w tworzeniu stron internetowych jestem na etapie kamienia łupanego. Mam strukturę plików z podkatalogami i nie mam pojęcia, jak to wszystko mógłbym scalić, żeby zadziałało na takim portalu.
Czy mógłbym przesłać jakoś spakowany fragment mojej strony? Taki fragment zajmuje mi na dysku niecałe 19 MB. Dzięki za chęć pomocy!

[krystian3w]

Najlepiej zrób wersje z 5 grafikami bezpłatnymi zamiast zdjęć babci.

[jwal2]

Dobra rada! Ale wolę się babci nie narażać, bo blisko mnie mieszka. A poza tym mam zdjęcia nie tylko babci, ale też dużo moich i mojej żony, na których mi zależy.

[jwal2]

Fragment swojej strony opublikowałem w Internecie. Można ją wywołać z adresu: http://walinscy.civ.pl/test/
Strona w Internecie działa. Dokładnie ta sama nie funkcjonuje, jeżeli jest wywołana lokalnie z dysku i nie zablokuję wcześniej wymienionego patcha. Przy patchu na false wszystko działa dobrze.
Niedawno sprawdzałem skrypty JS na tej stronie. Wyraźnie widać, że patch ten blokuje komunikację pomiędzy ramkami, np. kiedy z ramki frame3 usiłuję zrobić reload ramki frame1 lub z ramki1 chcę odczytać jakiś atrybut z framesetu. To wszystko oczywiście działa, kiedy wywołuję stronę z Internetu lub ma wyłączonego patcha.
Załączam html-owe pozdrowienia!

[dexter]

1. To nie jest patch, tylko po prostu opcja czy preferencja.

2. Nie mogę tego błędu odtworzyć na wersji 70, być może to oznacza że to poprawili.

[jwal2]

OK. Na razie dziękuję i poczekam do wersji 70.

[_Puma_]

U mnie też wszystko działa, nie widzę żadnych błędów.

Ps. Taki efekt uzyskasz używając php, a linki do zdjęć najlepiej trzymać w bazie danych. Wygodne i praktyczne. Ewentualnie użyj jakiś cms do katalogowania zdjęć.

[krystian3w]

U mnie nawet w stabilnym na WWW nie robi problemu.

Ale jak ręcznie pobrałem to widzę że się nie da klikać - babci musiałyś localhost odpalać np. z pythona.

Nightly 70 tego ani beta 69 nie zmieniają - wciąż wymagany minimum localhost z python / tiny.exe.

Jak błąd raportować to jako plik zip do rozpakowania.

[krystian3w]

Bardzo uproszczone demo do około kilku KiB:

frames.zip
https://www77.zippyshare.com/v/vlR7Tv6J/file.html

Onclick ma otwierać ramkę 4 tam gdzie była ramka 2 i wpis privacy.file_unique_origin to blokuje jak na przykładzie tej galerii (ona ma niby jeszcze 1 dodatkowy error oprócz wspólnego z tym uproszczeniem).

[krystian3w]

Myślę, że warto śledzić ten bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1565261

[dexter]

Bardzo uproszczone demo do około kilku KiB:

frames.zip
https://www77.zippyshare.com/v/vlR7Tv6J/file.html

Onclick ma otwierać ramkę 4 tam gdzie była ramka 2 i wpis privacy.file_unique_origin to blokuje jak na przykładzie tej galerii (ona ma niby jeszcze 1 dodatkowy error oprócz wspólnego z tym uproszczeniem).

To się zgadza.

[jwal2]

Czekając na wyjaśnienie tego problemu, zrobiłem nową wersję galerii, w której zrezygnowałem z framesetu i wszystko już działa, także przy wywołaniu lokalnym. Jednak dobrze by było, gdyby niezależnie od tego autorzy Firefoksa wprowadzili poprawki odblokowujące starą wersję galerii, bo to oszczędziłoby mi wiele czasu, potrzebnego na zmodyfikowanie setek plików html. Nowa wersja galerii wydaje się być o wiele prostsza, niż moja poprzednia, jednak tak często bywa, że do czegoś prostszego nie dochodzi się od razu. Bardzo dziękuję, że zajęliście się moim problemem.
Załączam link do fragmentu nowej wersji galerii: http://walinscy.civ.pl/test-nowy/

[krystian3w]

No nie jestem pewien, niby to fix na hackowanie z plików uruchomionych lokalnie.

Widać zabezpieczyli za mocno lub słabiej się na razie nie dało by uznać zagrożenia za załatane wystarczająco.

[krystian3w]

A sprawdź czy może jak w plikach poprzedzisz adresy kropkami - nie mam już do dyspozycji pierwszej wersji pobranej ręcznie z podglądów źródła stron by się mało różniła od oryginałów.

Kod: Zaznacz cały

<script src="./skrypt/plik.js">

niestety nie wiem czy onclick też by się nie oburzył za kropkę. I na ile jako zmienna w JS by to przechodziło.

[krystian3w]

Dzieje się, odblokowali fonty (jako pliki woff/woff2) w plikach lokalnych bez uruchamiania localhost czy myków z kropką:

https://bugzilla.mozilla.org/show_bug.cgi?id=1565942