Firefox preferences - some categories do not work if clicked too fast
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Confirmed
|
Medium
|
|||
firefox (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned | ||
firefox-3.0 (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned | ||
firefox-3.5 (Ubuntu) |
Triaged
|
Medium
|
Unassigned |
Bug Description
Binary package hint: firefox
I am using an up-to-date installation of hardy alpha 5 with firefox 3 beta 3.
What happens is the following: When I go to the preferences-window, some categories so not work. With categories I mean "Main", "Tabs", "Content" and so on. This means: Usually when I click on a category, the appropriate content is shown. However, when I click on categories that no not work, nothing happens (a.k.a the content from the category selected before is still showing). See attached screenshot, which shows the content of "Main", although "Security" is selected.
After each restart of firefox, other categories are affected. Which ones seems to be quite random.
In Mozilla Bugzilla #330458, Daniel-glazman (daniel-glazman) wrote : | #1 |
In Mozilla Bugzilla #330458, Nickolay Ponomarev (asqueella) wrote : | #2 |
From a duplicate:
Another testcase: http://
Additionally, the error console throws many exceptions (this from the trunk):
Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMXULDocum
"0x80004005 (NS_ERROR_FAILURE)" location: "JS frame ::
chrome:
data: no]
Also asserts for me:
###!!! ASSERTION: forward references have already been resolved: 'Error', file
c:/mozilla/
and leaks on shutdown.
In Mozilla Bugzilla #330458, Nickolay Ponomarev (asqueella) wrote : | #3 |
*** Bug 355038 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #330458, Mozilla-wild (mozilla-wild) wrote : | #4 |
I've just run into this bug. It's serious.
A separate extension was making calls to loadOverlay, causing the call in my extension to fail. It just happened to squeeze in first. Thus, sections of functionality were just plain missing.
For what it's worth, still in 2.0:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
In Mozilla Bugzilla #330458, Cbook (cbook) wrote : | #5 |
*** Bug 369481 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #330458, Nickolay Ponomarev (asqueella) wrote : | #6 |
Created attachment 255653
WIP
Need to make sure the load observers are processed correctly with this change and address the XXXs in the diff. Also need to convert my testcases to proper reftests (use window.location to work around inability to pass relative URLs to document.
In Mozilla Bugzilla #330458, Nickolay Ponomarev (asqueella) wrote : | #7 |
A comment in nsXULDocument.cpp claims we don't support loading the same overlay twice into the same document, because it "doesn't make sense anyway":
http://
In fact we do support it, both with document.
So how should this work?
In Mozilla Bugzilla #330458, Nickolay Ponomarev (asqueella) wrote : | #8 |
Created attachment 258243
WIP #2
Observers are handled correctly, but failures are not handled properly (like in the old code).
In Mozilla Bugzilla #330458, Pete-mozdevgroup (pete-mozdevgroup) wrote : | #9 |
Yea this blocks bug 328070
In Mozilla Bugzilla #330458, Dsicore (dsicore) wrote : | #10 |
Not a regression from 2.0. -'ing for 1.9.
Polvi is cool.
In Mozilla Bugzilla #330458, Kairo-kairo (kairo-kairo) wrote : | #11 |
do we really want to ship with this bug?
In Mozilla Bugzilla #330458, Nickolay Ponomarev (asqueella) wrote : | #12 |
> do we really want to ship with this bug?
We shipped 1.5 with document.
More to the point, this code is rather messy and doesn't care about *so* many cases, that making sure it works correctly in all code paths is quite hard.
It would be easy to cook up a patch to make successive loadOverlay calls work properly in the common cases, but then you're replacing a clear bug (only one overlay can be loaded at a time) with lots of subtle bugs and the risk to introduce security risks.
In Mozilla Bugzilla #330458, Nickolay Ponomarev (asqueella) wrote : | #13 |
(BTW I'm not working on this now and probably lost the more recent patch than what I have attached, so feel free to steal this one from me. You have been warned, though!)
In Mozilla Bugzilla #330458, Kairo-kairo (kairo-kairo) wrote : | #14 |
The problem is that apparently this prohibits pefpanes (which are loaded with this function) from being overlayed at all, which does not only reduce extensibility (which we probably want) but also would be something that SeaMonkey needs in our new toolkit-derived prefwindow: Once I overlay (with a conventional manifest-based overlay) the pane that's being loaded with loadOverlay(), the observer to that loadOverlay() call doesn't fire any more.
In Mozilla Bugzilla #330458, Mnyromyr (mnyromyr) wrote : | #15 |
> We shipped 1.5 with document.
> probably not such a big deal.
Sad to say, but Toolkit's prefwindow definitely isn't quite ready for realworld usage outside of simple cases like Firefox' prefpanes. See also bug 410562 and others.
> More to the point, this code is rather messy and doesn't care about *so* many
> cases, that making sure it works correctly in all code paths is quite hard.
>
> It would be easy to cook up a patch to make successive loadOverlay calls work
> properly in the common cases, but then you're replacing a clear bug (only one
> overlay can be loaded at a time) with lots of subtle bugs and the risk to
> introduce security risks.
Shouldn't it suffice to just queue the overlays and then walk back notifying the observers? You'd definitely don't want to load an overlay twice to avoid looping, but (simple) ested overlaying should work.
Which security risks do you expect? (While of course always possible, this pretty much sounds like a scarecrow here.)
In Mozilla Bugzilla #330458, Nickolay Ponomarev (asqueella) wrote : | #16 |
I remember very little about this code, so can't delve into technical discussion now. I wrote what was my impression from trying to patch up this code.
> Shouldn't it suffice to just queue the overlays
That's what I'm doing. The hard thing about this code is that
a) the call graph is quite complicated on its own (supporting many different scenarios - fastload vs no fastload, initial load vs dynamic overlay, etc)
b) certain callbacks happen asynchronously from the event loop (meaning that the document may be touched in the interim)
c) it used to be the case that certain spots in the code could cause scripts to run (which could cause our code to be reentered).
You have to be sure you get to the end of the load process in any case - to call all overlay observers. And you have to be sure you handle the async notifications properly whatever order they come in (and be some notification always happens, so that you don't live in the loading state forever).
With the WIP#2 patch (I think) I had the problem with cancelled (BINDING_ABORTED) loads not being processed correctly; in normal cases it seemed to work correctly, but touching this code causes paranoia, as you see.
re scarecrow: possibly, but overlays are available to content, and the reentrancy issues and the fact that the script is able to make unexpected changes to document's state while it is loading make me feel uncomfortable. I'm mainly afraid of crashes here.
Maybe you're right and we should implement the simple fix and deal with corner cases in separate bugs. Feel free to take it :) I'll try to see if I still have my tests somewhere (not until Monday probably).
A patch like this feels like an alpha material though.
In Mozilla Bugzilla #330458, Iann-bugzilla (iann-bugzilla) wrote : | #17 |
Created attachment 303723
Unbitrotted WIP patch v0.3
Unbitrotted to the extent that it builds and appears to work - only to be considered as a starting point for the moment.
In Mozilla Bugzilla #330458, Mnyromyr (mnyromyr) wrote : | #18 |
Created attachment 304557
different testcase, v1
Extract the contents of the zip into the extensions folder of a trunk nightly of SM or FF and open
chrome:
With patch attachment 303723 applied, each group has three green labels. Without it, the last two groups don't load completely and stay red.
Nickolay, any ideas how to test this BINDING_ABORTED problems you saw?
In Mozilla Bugzilla #330458, Mnyromyr (mnyromyr) wrote : | #19 |
Stuffing the overlay files with useless comments (eg. until they're 10 MB) allows to interrupt the loadOverlay calls. In this case, the testcase will fail - but I wouldn't expect it to work in this case anyway.
I didn't see any suspicious behaviour either, so maybe the testcase is just too simple for testing such edge case. Suggestions?
Otherwise, I'd suggest asking for first reviews...
In Mozilla Bugzilla #330458, Mnyromyr (mnyromyr) wrote : | #20 |
Comment on attachment 303723
Unbitrotted WIP patch v0.3
Okay, going for reviews then...
In Mozilla Bugzilla #330458, Jst (jst) wrote : | #21 |
Comment on attachment 303723
Unbitrotted WIP patch v0.3
Neil, I think you'd be a better reviewer for this than I would...
In Mozilla Bugzilla #330458, Nickolay Ponomarev (asqueella) wrote : | #22 |
Sorry, didn't find the tests. The binding_aborted thing was reproducible by stopping the load (e.g. using window.stop) after the loadOverlay call, iirc.
Thanks for taking this, I'd suggest fixing the XXXs (the stylistic one and notification-
In Mozilla Bugzilla #330458, Mnyromyr (mnyromyr) wrote : | #23 |
Grammar fixes can be applied once we know whether the actual code changes are okay or not. :)
In Mozilla Bugzilla #330458, Bzbarsky (bzbarsky) wrote : | #24 |
I doubt I'll be able to sr this in any sort of reasonable timeframe (most likely, not until June at best).
In Mozilla Bugzilla #330458, Hskupin (hskupin) wrote : | #25 |
*** Bug 415152 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #330458, Hskupin (hskupin) wrote : | #26 |
Bug 415152 which is now duped against this one has blocking-firefox3+. Reasking for blocking-1.9.
Data (ubuntuaddress) wrote : [Hardy alpha 5] Firefox preferences - some categories to not work | #27 |
Binary package hint: firefox
I am using an up-to-date installation of hardy alpha 5 with firefox 3 beta 3.
What happens is the following: When I go to the preferences-window, some categories so not work. With categories I mean "Main", "Tabs", "Content" and so on. This means: Usually when I click on a category, the appropriate content is shown. However, when I click on categories that no not work, nothing happens (a.k.a the content from the category selected before is still showing). See attached screenshot, which shows the content of "Main", although "Seurity" is selected.
After each restart of firefox, other categories are affected. Which ones seems to be quite random.
Data (ubuntuaddress) wrote : | #28 |
Data (ubuntuaddress) wrote : | #29 |
OK, I just found out:
When opening the preferences the first time (=after firefox started) and then cycle through the different categories quite fast, so that I select another category before the current one had a chance to load, the bug occurs.
Those categories, that did not have time to load, are those that do not work afterwards (as described above).
In Mozilla Bugzilla #330458, Dsicore (dsicore) wrote : | #30 |
Discussed with mconnor & beltzner regarding the blocking status of Bug 415152. That bug is a P4 and is being moved to the next 0.x release. Marking this bug accordingly.
Also, can't reproduce. Anyone have more info?
In Mozilla Bugzilla #330458, Stephen-donner (stephen-donner) wrote : | #31 |
(In reply to comment #27)
> Discussed with mconnor & beltzner regarding the blocking status of Bug 415152.
> That bug is a P4 and is being moved to the next 0.x release. Marking this bug
> accordingly.
>
> Also, can't reproduce. Anyone have more info?
I can reproduce 100%, unfortunately. If you can reproduce, would you restore blocking?
In Mozilla Bugzilla #330458, Hskupin (hskupin) wrote : | #32 |
(In reply to comment #27)
> Also, can't reproduce. Anyone have more info?
It's very easy to reproduce. Open the preferences panel and hold down the left or right arrow key to immediately switch as fast as possible through the several panes. Do this for one cycle. Afterwards you will see the error message within the Error Console. Tested with OS X 10.4.11.
In Mozilla Bugzilla #330458, Enn (enndeakin) wrote : | #33 |
Comment on attachment 303723
Unbitrotted WIP patch v0.3
Why is a review requested on this patch if its author does not think it is ready?
In Mozilla Bugzilla #330458, L. David Baron (dbaron) wrote : | #34 |
Is this a regression? (It doesn't look like it is.) If not, what's the case that it actually *blocks* the release?
In Mozilla Bugzilla #330458, Stephen-donner (stephen-donner) wrote : | #35 |
Seems like a regression to me, since I can't reproduce anything like this in Firefox 2 on Mac.
https:/
Case that it *blocks* the release?: when switched to after following the above steps, the preference panels' contents will be empty until the window is closed and reopened. I had as many as three panels in this state while testing.
(Additionally, there is a smattering of embedding issues which I don't really claim to fully understand.)
In Mozilla Bugzilla #330458, Nickolay Ponomarev (asqueella) wrote : | #36 |
This core bug is not a regression, since the bug is basically about the overlay queueing code that never was written.
The case for blocking is platform quality, I suppose. Without this bug fixed seamonkey folks will have additional trouble implementing their preferences the way they want it. And this introduces an additional way for extensions to conflict.
In Mozilla Bugzilla #330458, Daniel-glazman (daniel-glazman) wrote : | #37 |
(In reply to comment #32)
> Seems like a regression to me, since I can't reproduce anything like this in
> Firefox 2 on Mac.
It's not a regression. It basically never worked.
In Mozilla Bugzilla #330458, Stephen-donner (stephen-donner) wrote : | #38 |
(In reply to comment #34)
> (In reply to comment #32)
> > Seems like a regression to me, since I can't reproduce anything like this in
> > Firefox 2 on Mac.
>
> It's not a regression. It basically never worked.
I should've been more clear; my originally filed bug, bug 415152, which was duped to this (and had blocking before), is clearly a regression from Firefox 2 -> 3 on Mac.
In Mozilla Bugzilla #330458, Hskupin (hskupin) wrote : | #39 |
(In reply to comment #35)
> I should've been more clear; my originally filed bug, bug 415152, which was
> duped to this (and had blocking before), is clearly a regression from Firefox 2
> -> 3 on Mac.
Sadly the latter one isn't true. I used the described STR from my comment 29 and it is reproducible with the latest 1.8.1 nightly build. At least two panels were empty.
John Vivirito (gnomefreak) wrote : Re: [Hardy alpha 5] Firefox preferences - some categories to not work | #40 |
Sorry but Firefox-2 is getting near EOS and they wont be fixing anything but major issues security issues mainly. Please try to reproduce this with Firefox-3.0 if you can reproduce this bug please click on Help > Report a problem and file the bug that way. This does not mean that it wasn't already fixed.
Changed in firefox: | |
status: | New → Won't Fix |
Data (ubuntuaddress) wrote : | #41 |
The bug is still present in an up-to-date installation of hardy (firefox 3beta5).
John, I do not really understand why you mention firefox-2 as firefox-2 was never mentioned in this bugreport.
So I am setting this bug status back to New, so that someone else can confirm it.
Also I do not understand why it should be better to file a new bug for this issue as this bugreport here already exists. But maybe I am missing something here (Is it better to file a report by using Help > Report a problem than just filing a bug in lauchpad like this one?), so feel free to correct me, if necessary.
Changed in firefox: | |
status: | Won't Fix → New |
description: | updated |
John Vivirito (gnomefreak) wrote : Re: [Hardy] Firefox preferences - some categories do not work if clicked too fast | #42 |
"Binary package hint: firefox" that is why i said firefox-2 the package would be firefox-3.0 if it was ff3 changing to be correct.
This sounds like something more on pc than a bug. can you please try with a clean profile see https:/
At this moment i am unable to reproduce this bug.
Changed in firefox: | |
status: | New → Incomplete |
Alexander Sack (asac) wrote : Re: [Bug 197781] Re: [Hardy alpha 5] Firefox preferences - some categories to not work | #43 |
On Mon, May 12, 2008 at 01:33:28PM -0000, Data wrote:
> The bug is still present in an up-to-date installation of hardy (firefox 3beta5).
> John, I do not really understand why you mention firefox-2 as firefox-2 was never mentioned in this bugreport.
> So I am setting this bug status back to New, so that someone else can confirm it.
> Also I do not understand why it should be better to file a new bug for this issue as this bugreport here already exists. But maybe I am missing something here (Is it better to file a report by using Help > Report a problem than just filing a bug in lauchpad like this one?), so feel free to correct me, if necessary.
>
> ** Changed in: firefox (Ubuntu)
> Status: Won't Fix => New
>
firefox 3 is tracked by a different source package
affects ubuntu/firefox-3.0
status new
firefox ships firefox 2 now
affects ubuntu/firefox
status wontfix
- Alexander
Changed in firefox-3.0: | |
status: | Incomplete → New |
Data (ubuntuaddress) wrote : Re: [Hardy] Firefox preferences - some categories do not work if clicked too fast | #44 |
@asac:
Sorry, didn't know, that package firefox was actually firefox 2. Thanks for changing the affected packages!
@John:
I tried to trigger the bug on two different notebooks and also with a clean profile, as you suggested and it is still present, although, it is harder to trigger the bug on faster computers (as the bug only occurs when a "tab" in the preferences-window couldn't be loaded, because the user switched to a different "tab" fast enough).
Quite a certain way to trigger the bug is:
1. Open Preferences
2. Use the tab-key to change the focus until the "tab"-bar is selected.
3. Press "left"-
4. Now click each "tab" and see that "tabs" some do not show any content/ the content does not change when changing tabs.
Maybe you could try again to trigger the bug on your machine?
(This bug does not seem to be very noticeable/annoying on fast machines but it is really annyoing when using a slow computer or in a virtual machine)
John Vivirito (gnomefreak) wrote : Re: [Bug 197781] Re: [Hardy] Firefox preferences - some categories do not work if clicked too fast | #45 |
>
> Data wrote:
>
>> > @asac:
>> > Sorry, didn't know, that package firefox was actually firefox 2. Thanks for changing the affected packages!
>> > @John:
>> > I tried to trigger the bug on two different notebooks and also with a clean profile, as you suggested and it is still present, although, it is harder to trigger the bug on faster computers (as the bug only occurs when a "tab" in the preferences-window couldn't be loaded, because the user switched to a different "tab" fast enough).
>> >
>> > Quite a certain way to trigger the bug is:
>> >
>> > 1. Open Preferences
>> > 2. Use the tab-key to change the focus until the "tab"-bar is selected.
>> > 3. Press "left"-
>> > 4. Now click each "tab" and see that "tabs" some do not show any content/ the content does not change when changing tabs.
>> >
>> > Maybe you could try again to trigger the bug on your machine?
>> >
>> > (This bug does not seem to be very noticeable/annoying on fast machines
>> > but it is really annyoing when using a slow computer or in a virtual
>> > machine)
>> >
>> >
>>
I will see what i can do to reproduce this with new steps given, Can you
please list specs of you pc as in processor type and rating(400mhz or
whatever) also amount of memory in PC graphics card and drivers that you
use.
Also does this happen with and without desktop effects enabled?
--
Sincerely Yours,
John Vivirito
https:/
https:/
Linux User# 414246
Alexander Sack (asac) wrote : Re: [Hardy] Firefox preferences - some categories do not work if clicked too fast | #46 |
i can reproduce this. confirmed. could you please test with latest nightlies from http://
Changed in firefox-3.0: | |
status: | New → Confirmed |
Data (ubuntuaddress) wrote : | #47 |
sorry for the delay, guys...
@John:
It happens both on my old notebook (1.4 Ghz Pentium M, 512MB RAM, 16 MB Intel Graphics card with shared memory), on my new notebook (1.5 Ghz Intel Core 2 Duo, 2 GB RAM, 256 MB intel Graphics card with shared RAM) and on every Virtualbox installation of hardy).
It also happens with and without compiz enabled.
I really don't think this is a graphics-related issue. I think the elements (buttons, text fields, etc) inside the tabs that are not showing are really not loaded (not just not shown due to some graphics glitch).
@asac:
I tested with firefox3.0RC1 (from ppa.launchpad.
Alexander Sack (asac) wrote : Re: [Bug 197781] Re: [Hardy] Firefox preferences - some categories do not work if clicked too fast | #48 |
On Thu, May 22, 2008 at 11:09:59AM -0000, Data wrote:
> @asac:
> I tested with firefox3.0RC1 (from ppa.launchpad.
>
ok. this should be a xulrunner issue then and we should see if its
already reporter in bugzilla.
indicate this.
For now, please try to find the right bug id in bugzilla.
affects firefox
status incomplete
Thanks,
- Alexander
Data (ubuntuaddress) wrote : Re: [Hardy] Firefox preferences - some categories do not work if clicked too fast | #49 |
I thoroughly looked through the firefox bugs in bugzilla.
The closest bug to this one I could find was: https:/
But I am pretty sure that's a different bug.
So could someone else please report this bug to the bugzilla? (As I do not have a bugzilla account...)
That would be great!
In Mozilla Bugzilla #330458, Stephen-donner (stephen-donner) wrote : | #50 |
*** Bug 440425 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #330458, Mozilla-tibit (mozilla-tibit) wrote : | #51 |
I run Firefox 3.0 on Linux, and this seems to be the problem I ran into with certain preferences panes just the other day.
In Mozilla Bugzilla #330458, Alice0775 (alice0775) wrote : | #52 |
This problem causes the problem for dynamic loading of editBookmarkOve
When the timing of clicking the star button and other dynamic loadings is almost same time, "Edit Bookmarks panel" is not displayed.
This is a very serious problem.
Alexander Sack (asac) wrote : Re: [Hardy] Firefox preferences - some categories do not work if clicked too fast | #53 |
this is somewhat https:/
Changed in firefox-3.0: | |
status: | Confirmed → Triaged |
Changed in firefox: | |
importance: | Undecided → Unknown |
status: | Incomplete → Unknown |
Changed in firefox: | |
status: | Unknown → Confirmed |
In Mozilla Bugzilla #330458, Yan-morin (yan-morin) wrote : | #54 |
In the documentation on https:/
Currently, I try to load two overlays with this pattern:
1. call the loading function
1.1 loadOverlay(
2. observer::observe is called with the good signal
RESULT = the document 1 is loaded
2.1 recall the loading function
2.2 loadOverlay(
3 <observer.observer is never called>
RESULT = the document 2 is loaded, but the event was not fired
I'm trying to use loadOverlay because I have a system that work with modules (actived depending on user rights known on runtime after a login dialog). Rights now I have the choice to load all overlays (wait about 30 seconds for xulrunner to open) or open the core system (wait around 10 seconds).
So, can you paste me some code that will help me to understand how to load more than 1 overlays?
In Mozilla Bugzilla #330458, Alice0775 (alice0775) wrote : | #55 |
The following code can load more than 1 overlays.
usage :
myLoadoverlay.
myLoadoverlay.
myLoadoverlay.
Will run in the following order:
load urlA, execute observerA, load urlB, load urlC, execute observerC
//myLoadoverlay
var myLoadoverlay = {
overlayWait:0,
overlayUrl:[],
loadOverlay: function(url, observer, doc) {
if (!myLoadoverlay
},
load: function() {
if (!myLoadoverlay
return --myLoadoverlay
var [url, aObserver, doc] = this.overlayUrl
if (!doc)
doc = document;
if (!aObserver)
aObserver = myLoadoverlay.
else {
var func = aObserver.
func = func.replace(
}
var original_
try {
} catch(ex) {
}
return 0;
},
observer: {
observe : function (subject, topic, data) {
if (topic == 'xul-overlay-
}
},
QueryInte
&& !aIID.equals(
throw Components.
return this
}
},
error: function(aMsg, err){
const CONSOLE_SERVICE = Components.
var error = Components.
if (typeof(err) == 'object')
else
CONSOLE_
}
}
In Mozilla Bugzilla #330458, Yan-morin (yan-morin) wrote : | #56 |
Sorry for the latest comment, but I tested more, created a test case on
http://
My second overlay has 3 overlays.
When you try to load overlay that have overlays, it doesn't fire the merge signal.
In Mozilla Bugzilla #330458, Alice0775 (alice0775) wrote : | #57 |
(In reply to comment #42)
I think that it is not the contents about which it should argue here.
Please argue by the following forums.
http://
In Mozilla Bugzilla #330458, Bugzilla-mozilla-org-erik (bugzilla-mozilla-org-erik) wrote : | #58 |
I have found that if the overlay references a stylesheet with the <?xml-stylesheet ... ?> link then any observer based queuing system loads the first overlay and then fails to load subsequent items in the queue (I tried my own one and also the one above written by Alice White). If I take out the stylesheets it works. It would seem that Yan Morin is correct when he comments about signals not being fired when you would expect them to be. I don't know what Mozilla's policy is on overlays but I would hope that the observer would be triggered with a success/failure result regardless of what stylesheets or other overlays were referenced in the one you tried to load.
I'm not willing to keep the CSS for each overlay in the main stylesheet for my Firefox extension and the only way I've found so far to load multiple overlays in a specific sequence, each with their own CSS and JS files, is to use the timer based technique shown below. The presence of the loaded overlay is detected by checking for an element known to exist in the overlay. The observer is not used as it's useless in the current state of affairs.
var overlay_loader={
queue: [],
loading: false,
add: function(url,id)
{
this.
},
load: function()
{
if(
{
this.
document.
}
else
{
if(
{
}
}
setTimeout(
},
observe: function(
{
// don't bother to do anything because we cannot
// guarantee that this observer will be called anyway
}
}
You would use this in the following way:
overlay_
overlay_
overlay_
In Mozilla Bugzilla #330458, Nickolay Ponomarev (asqueella) wrote : | #59 |
Erik: please file that issue (observer not firing) as a separate bug. Most likely, it's an issue that needs to be dealt with before this bug is fixed, since the fix to this bug would likely just implement the queuing system inside document.
In Mozilla Bugzilla #330458, Hskupin (hskupin) wrote : | #60 |
Karsten, do you wanna still be the assignee of this bug?
In Mozilla Bugzilla #330458, Mnyromyr (mnyromyr) wrote : | #61 |
Not working on this.
In Mozilla Bugzilla #330458, Hskupin (hskupin) wrote : | #62 |
So how can we proceed with this bug? It's laying around for a couple of years now.
In case of QAE it blocks us from writing a couple of Mozmill tests because the preferences dialog produces some unpredictable behavior. See bug 499691. We don't use observers but whether which timing we are using tests will timeout because panes don't get loaded and displayed.
In Mozilla Bugzilla #330458, Bzbarsky (bzbarsky) wrote : | #63 |
> So how can we proceed with this bug?
Find someone who has time on their hands to deal with the completely broken crap that is loadOverlay?
Data (ubuntuaddress) wrote : Re: [Hardy] Firefox preferences - some categories do not work if clicked too fast | #64 |
Bug is still present in Firefox 3.5 in Karmic alpha 6
In Mozilla Bugzilla #330458, Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing) wrote : | #65 |
Micah Gersten (micahg) wrote : Re: [Hardy] Firefox preferences - some categories do not work if clicked too fast | #66 |
Firefox 3.0 is only receiving Security Updates and major bug fixes at this point.
Changed in firefox-3.0 (Ubuntu): | |
status: | Triaged → Won't Fix |
Micah Gersten (micahg) wrote : | #67 |
Moving tracking to Firefox 3.5...most likely won't be fixed until 3.6 or later, but we need to track somewhere.
Changed in firefox-3.5 (Ubuntu): | |
importance: | Undecided → Medium |
status: | New → Triaged |
summary: |
- [Hardy] Firefox preferences - some categories do not work if clicked too - fast + Firefox preferences - some categories do not work if clicked too fast |
In Mozilla Bugzilla #330458, Christian-pingroom (christian-pingroom) wrote : | #68 |
modified version of Erik's one to enable multiple load calls :
var OverlayLoader = {
queue: [],
loading: false,
add: function(url,id)
{
OverlayLoad
},
load: function()
{
if (OverlayLoader.
if (!OverlayLoader
{
OverlayLo
document.
}
else
{
if (document.
{
if (OverlayLoader.
}
}
setTimeout(
}
};
overlay_
overlay_
----
overlay_
overlay_
usefull for us, when loading overlays in more than one extension at the same time.
In Mozilla Bugzilla #330458, Daniel-glazman (daniel-glazman) wrote : | #69 |
(In reply to comment #51)
> document.
...
> setTimeout(
Using a timeout here seems the very wrong way to go. Why don't you use an
observer as second argument to your loadOverlay() call? That way, you can
really know when the overlay is merged and pop another one from the queue.
In Mozilla Bugzilla #330458, Bugzilla-mozilla-org-erik (bugzilla-mozilla-org-erik) wrote : | #70 |
(In reply to comment #52)
> Why don't you use an observer as second argument to your loadOverlay() call?
If you look at comment 44 you'll see that I mentioned the problem whereby the observer is not fired if the overlay contains XML references to other overlays (stylesheets, scripts or other overlays).
In Mozilla Bugzilla #330458, Nickolay Ponomarev (asqueella) wrote : | #71 |
(In reply to comment #53)
> If you look at comment 44 you'll see that I mentioned the problem whereby the
> observer is not fired if the overlay contains XML references to other overlays
> (stylesheets, scripts or other overlays).
(Which you filed as bug 496320, but never mentioned here, so it was never looked at.)
Changed in firefox: | |
importance: | Unknown → Medium |
In Mozilla Bugzilla #330458, Frommozdev-orghash69 (frommozdev-orghash69) wrote : | #72 |
Is this bug still exists in version 24???
MDN still referring to it
https:/
Changed in firefox: | |
status: | Confirmed → Unknown |
Changed in firefox: | |
status: | Unknown → Confirmed |
cc:ing Ben