AUTOMATIC1111 / stable-diffusion-webui

Stable Diffusion web UI
GNU Affero General Public License v3.0
139.41k stars 26.43k forks source link

[Bug]: Gallery opens next image in Firefox (115.14.0esr) #16390

Open lunixhub opened 3 weeks ago

lunixhub commented 3 weeks ago

Checklist

What happened?

When generating images in txt2img using Firefox, clicking on an image to enlarge opens the next one instead and the gallery switches to the next image too.

Steps to reproduce the problem

  1. Generate a batch of images.
  2. Click on any image in gallery.
  3. The next image in the gallery opens.

What should have happened?

The image that was selected when clicked on should have opened.

What browsers do you use to access the UI ?

Mozilla Firefox

Sysinfo

sysinfo-2024-08-15-18-45.json

Console logs

venv "C:\Users\XXXXXXX\stable-diffusion-webui\venv\Scripts\Python.exe"
Python 3.10.6 (tags/v3.10.6:9c7b4bd, Aug  1 2022, 21:53:49) [MSC v.1932 64 bit (AMD64)]
Version: v1.10.1
Commit hash: 82a973c04367123ae98bd9abdf80d9eda9b910e2
Launching Web UI with arguments: --xformers --medvram-sdxl
ControlNet preprocessor location: C:\Users\XXXXXXX\stable-diffusion-webui\extensions\sd-webui-controlnet\annotator\downloads
2024-08-15 20:48:24,058 - ControlNet - INFO - ControlNet v1.1.455
Loading weights [fe7578cb5e] from C:\Users\XXXXXXX\stable-diffusion-webui\models\Stable-diffusion\1.5\Real\realisticVisionV60B1_v60B1VAE.safetensors
Creating model from config: C:\Users\mir\stable-diffusion-webui\configs\v1-inference.yaml
C:\Users\XXXXXXX\stable-diffusion-webui\venv\lib\site-packages\huggingface_hub\file_download.py:1150: FutureWarning: `resume_download` is deprecated and will be removed in version 1.0.0. Downloads always resume when possible. If you want to force a new download, use `force_download=True`.
  warnings.warn(
2024-08-15 20:48:24,388 - ControlNet - INFO - ControlNet UI callback registered.
Running on local URL:  http://127.0.0.1:7860

To create a public link, set `share=True` in `launch()`.
Startup time: 16.6s (prepare environment: 6.2s, import torch: 2.7s, import gradio: 1.5s, setup paths: 1.5s, initialize shared: 1.3s, other imports: 0.9s, load scripts: 1.6s, create ui: 0.5s, gradio launch: 0.2s).
Applying attention optimization: xformers... done.
Model loaded in 2.4s (create model: 0.5s, apply weights to model: 1.0s, calculate empty prompt: 0.8s).
100%|...| 20/20 [00:03<00:00,  5.34it/s]
100%|...| 20/20 [00:02<00:00,  8.23it/s]

Additional information

I used fresh profile of Firefox 115.14.0esr. It works on Microsoft Edge.

There was an old bug report of this 2y ago #5941 but it says it was fixed, but its bugged now.

w-e-w commented 3 weeks ago

I was able to verify that this bug does indeed exist on Firefox 115.14.0esr

I tested using Windows sandbox and installing Firefox 115.14.0esr

however this bug is no longer present in current version of Firefox 129.0.1

~~Firefox 115.0 was Release July 4, 2023 considering that your version of Firefox is over a year old, you should upgrade your Firefox just for the security fixes if nothing else~~

oh 115.14.0 is ESR ......

lunixhub commented 3 weeks ago

however this bug is no longer present in current version of Firefox 129.0.1

This is good news, thanks for the info.

Firefox 115.0 was Release July 4, 2023 considering that your version of Firefox is over a year old, you should upgrade your Firefox just for the security fixes if nothing else

No my Firefox is up to date, it is the ESR release, meaning all security patches for extended period.

P.S. hehe i cannot deny I am amused how such a simple thing as clicking images raises trouble. In my mind technology is not always for the better, it also makes thing complicated to the extreme and prone to failures. People should use KISS whenever possible ;) Anyway, thanks to everybody for this nice software and your work

w-e-w commented 3 weeks ago

note as I'm not a web dev take what I said with a grain of salt

from my investigation this is a bug with Firefox 115.14.0esr

it seems to apply for multiple version of 115.x

when a browser executes a events capturing phase event should be executed followed by processing bobbing phase events

this is a minimum web page to demonstrate this behavior

<!DOCTYPE html>
<body>
    <button type="button" id="demo">Onen consol then click me</button>
    <script>
        const e = document.getElementById('demo');
        e.addEventListener('click', function(event) {console.log('Bubbling phase - 1')});
        e.addEventListener('click', function(event) {console.log('Bubbling phase - 2')});
        e.addEventListener('click', function(event) {console.log('Capturing phase - 1 ')}, true);
        e.addEventListener('click', function(event) {console.log('Capturing phase - 2')}, true);
        e.addEventListener('click', function(event) {console.log('Bubbling phase - 3')});
        e.addEventListener('click', function(event) {console.log('Capturing phase - 3')}, true);
    </script>
</body>
</html>

and this is expected output when the button is clicked

Capturing phase - 1 
Capturing phase - 2
Capturing phase - 3
Bubbling phase - 1
Bubbling phase - 2
Bubbling phase - 3

you can see that all capturing events are executed before the first bubbling event

and this is true for most browsers I have tested which includes Chrome 127.0.6533.119 Edge 127.0.2651.98 Firefox 129.0.1 128.1.0esr

the only exception is Firefox 115.14.0esr, this is the output

Bubbling phase - 1
Bubbling phase - 2
Capturing phase - 1
Capturing phase - 2
Bubbling phase - 3
Capturing phase - 3

from my observations it would seem like a Firefox 115.14.0esr executes events in the order they are registered and don't respect capturing bubbling, this could happen because you're breaking lots of websites if they relies on capturing events being executed before bobbing events


the reason why it causes an issue for web UI is that the "full screen image viewer" is not a part of the default gradio framework it is an addition that we add on top of the gradio gallery element

by default the when clicked the gallery element will switch to the next image we override this behavior by implementing our click event that shows our full screen image viewer in the event we also called the stopPropagation(), calling this inside capturing events will prevent bubbling events from being executed, and we use this to stop it from switching to the next image but as Firefox 115.14.0esr doesn't respect doesn't respect capturing event should be executed before bubbling events it fails to block image from being switched, because the image has already been switched


I was considering filing a bug report to Firefox about this but then I saw the 128.1.0esr is out so there is not much reporting a bug that has already been resolved somewhere in between 115~128

according to Firefox ESR release cycle

The ESR version will also have a three cycle (at least 12 weeks) overlap between the time of a new release and the end-of-life of the previous release to permit testing and certification before you deploy the new version to your organization. since 128.1.0esr

considering that the bug is not in 128.1.0esr and 115.14.0esr should be replace in 12~ weeks my I assessment is that I don't think there's much point in us trying to come up with a fix for an issue that would soon go away

gcp commented 5 days ago

FYI this is https://bugzilla.mozilla.org/show_bug.cgi?id=1492446 and https://bugzilla.mozilla.org/show_bug.cgi?id=1731504#c6. HTML spec on this changed a few times.

this could happen because you're breaking lots of websites if they relies on capturing events being executed before bobbing events

That's indeed what happened. Using the new spec behavior broke eBay for a while. First release version to default the new behavior was Firefox 119 (https://bugzilla.mozilla.org/show_bug.cgi?id=1840620).