2.0rc8 introduced some placeholder and icon issues

[al_9x]

Fx 3.6.8, NS 2.0rc8 - 2.0.1 (2.0rc7 is ok), new profile, block all embeddings on trusted, allow (justin.tv, jtvnw.net)

1) load any justintv profile (http://www.justin.tv/justin)
2) if you don't touch anything in the browser, after loading is finished, there will be no placeholders and the icon is either or
3) if you scroll to the bottom after loading or open the NS menu, the icon may change to the correct one and placeholders may appear

another thing is that since 2.0rc8, on some sites, placeholder creation is noticeably delayed. in one particular case, my router page with a doc.written flash header, is this delay deliberate?

[Giorgio Maone]

WFM on 2.0.1 and 2.0.1rc5...

[al_9x]

Do you see anything in 2.0rc8 (it definitely started there) changes that might cause this?

What about the somewhat delayed placeholder creation (at least for doc.written <objects>)?

[al_9x]

Definitely timing.

When my download bandwidth was maxed out with multiple connections (not firefox), making page loading in firefox much slower, it became less consistent, actually worked more often than not. As soon as I stopped that background traffic, speeding up Fx loading, the problem again became consistent.

[Giorgio Maone]

Could you check latest development build?

[al_9x]

Could you check latest development build?

There is a slight improvement, but not fixed.

1) the icon is ok nearly all time after f5
2) and wrong nearly all the time after ctrl-f5
3) and wrong nearly all the time if page is loaded from about:blank rather than refreshed
4) placeholders are still missing, perhaps less frequently than 2.0.1
5) a symptom I hadn't noticed before - even after you get the correct icon and placeholders (by scrolling to the bottom), if you switch to another tab (about:blank) and switch back, the icon isn't updated, it remains that of the about:blank tab

You never answered about the second issue, is the delayed placeholder creation I am seeing deliberate? side effect? The quicker creation in 2.0rc7 looks better, not as much of a flashing effect.

[therube]

> delayed placeholder creation

Is that; Notifications -> Show message about blocked scripts ?
If so, my impression has been that display has always been delayed till page has focus.

[Giorgio Maone]

2.0rc8 changes the way the plugin-blocking machinery causes UI syncrhonization, switching to an observer pattern which will easier to manage when Electrolysis becomes an issue.
That said, it should be expected to work exactly the same as before, so I'm quite puzzled. Did you say you can observe this behavior (especially the tab-switching one, which shouldn't be affected by this change at all) consistently on clean profiles?

[al_9x]

1) The tab switching icon issue turns out predates 2.0rc8, so its a separate issue, but it's specific to the justintv channel pages, the root page for example doesn't have this problem.

2) New profiles, consistently

3) This is the fourth time I am asking about the noticeable delay in placeholder creation, resulting in more of a flashing effect. Is this also due to the "observer pattern?"

[Giorgio Maone]

3) This is the forth time I am asking about the noticeable delay in placeholder creation, resulting in more of a flashing effect. Is this also due to the "observer pattern?"

No it's not. It was due to UI syncs triggered by plugin blocking being (intentionally) ignored before DOMContentLoaded, for performance reasons.
This optimization has been dropped in 2.0.2rc1, though, therefore you shouldn't observe it anymore.

[al_9x]

This optimization has been dropped in 2.0.2rc1, though, therefore you shouldn't observe it anymore.

I am not seeing any change with respect to the delay in 2.0.2rc1. I am looking at 2.0rc7 and 2.0.2rc1 side by side, refreshing my router page, a youtube video page. In 2.0rc7 the placeholder appearance is nearly instantaneous, in 2.0.2rc2 there is a longer delay. The placeholder area background is first black then the lighter placeholder appears, this creates more of visible "flashing" effect. This is obviously no showstopper, but it was better before.

[Giorgio Maone]

Could you please check latest development build, which has a slight deferring algorithm change?

[al_9x]

Could you please check latest development build, which has a slight deferring algorithm change?

Fixed on all counts, thanks, what was it?

[Giorgio Maone]

Could you please check latest development build, which has a slight deferring algorithm change?

Fixed on all counts, thanks, what was it?

Well, actually I just changed something which worked the same way for more than a couple of years now, i.e. the UI synchronization deferring/coalescing machinery.
The way it used to work was that every time a sync was needed (e.g. because a new embedding had been blocked during page load) this was signaled (through a direct method call until 2.0rc8, through a global observers notification now) and a timer was created to defer it by 400 millisecs. If a previous "sync request" timer was found, it was cancelled. When the timer fired, the currently focused window was compare with the one which caused the synchronization to be needed, and if the two matched the actual synchronization (which is a relatively costly operation because it involves DOM manipulation, and can take up to 20-30 millisecs on old CPUs or mobile platforms) happened.
This caused multiple sync requests to "move forward" the actual operation, which was performed only when the situation had been "quiet" for 400 millisecs at least or if the DOM was ready, or the load was completed, or the tab had been just selected (these latter 3 events cause an immediate sync).

What I did in 2.0.1rc2 has been changing the policy above as follows: if a previously created timer is found, it is left alone and no new timer is created. When the timer fires, it synchronizes the with the currently focused window, no matter what. Any "immediate" synchronization (DOM ready, load complete or tab switch) cause the timer to be cancelled.
This ensures any micro-event (blocked content) requiring synchronization not to wait more than 400 millisecs (they are all coalesced to the nearest sync in 400 millisecs trains).

[al_9x]

The placeholder delay issue I thought was fixed but I just ran into an example of it on a very simple test page:

Code: Select all

<iframe src="http://example.org"></iframe>

Compare the loading of the above in 2.0rc7 vs. 2.0.5.1

In 2.0rc7 the placeholder creation is instantaneous, as you reload you don't even see the page without it.
In 2.0.5.1 you first see a white box with a border, then after a delay the colored placeholder is painted.

This staggered placeholder creation with its background color transition creates a distracting flashing effect.