gryf/pentadactyl-pm
1
0
Fork 0
mirror of https://github.com/gryf/pentadactyl-pm.git synced 2026-01-03 06:54:12 +01:00
Code Issues Projects Releases Wiki Activity

Fix completions for FF3.6

Browse Source 
Also see: https://bugzilla.mozilla.org/show_bug.cgi?id=510589
This commit is contained in:
Martin Stubenschrott
2009-08-14 23:45:42 +02:00
parent e842bf8cc9
commit fb44ca22dc
5 changed files with 19 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
common/content/ui.js
View File

@@ -402,28 +402,11 @@ function CommandLine() //{{{
{
function done() !(idx >= n + context.items.length || idx == -2 && !context.items.length);
while (context.incomplete && !done())
// threadYield(true, true) would be better, but it does not return on my
// machine until all awesomebar completions were reported, making
// :open foo<tab> nearly unusable, if the first 2 foo-completions would
// be there fast, but it takes up to 20 sec to find more foo-completions
//
// The strange thing is, I tested the 2009-01-07 nightly at work in Windows
// and it seemed to work perfectly there. Will have to see if it's a
// hardware (dual core there, vs. P4 at home) issue or an OS issue.
//
// While I *really* prefer this solution over my hack
// when it works, we can't have a nearly-defect :open
// prompt when releasing vimp 2.0, even not just on certain
// computers, as :open is probably the most often used ex-command
// in vimperator
//
// liberator.threadYield(false, true); is just a temporary measure as
// it has other problems (hitting tab often in a row), until we find the
// source of the problem (which we hopefully do, as I really don't want to
// have to revert to my hack when better solutions exist)
liberator.threadYield(false, true);
if (done())
break;
n += context.items.length;
}
}