scrolling down in a .js file is very hard. jumps and flickers a lot on my really old and slow pentium 4 HT 2.8GHz (1 core 2 threads) on firefox 18.0.
also, there is another problem where sometimes if the code syntax is bad js won't execute it and the debugger won't kick out an error either. js and debugger just give up. it just sits there (both browser and debugger). browser is scrollable though, unlike during debugging sessions (which I suppose can be expected since scroll events are probably DOM and js events). not sure about this condition. maybe js cuts itself off from the world if the syntax is bad enough "I throw up my hands" type of thing? :-) some of my function calls were missing newly added arguments, etc.
I have about 2400 lines of code in this one js file, and sometimes when i scroll it or page it down, it doesn't always do a hot job of displaying - sometimes it displays all white instead of my code. try scrolling time-funcs.js when browsing the page http://Jesusnjim.com/common/js-stringtodtime.html this is purely a debug page and not intended for public consumption.
On Sunday, January 13, 2013 11:45:46 PM UTC-8, Jim Michaels wrote:
> scrolling down in a .js file is very hard. jumps and flickers a lot on my > really old and slow pentium 4 HT 2.8GHz (1 core 2 threads) on firefox 18.0.
> also, there is another problem where sometimes if the code syntax is bad > js won't execute it and the debugger won't kick out an error either. js and > debugger just give up. it just sits there (both browser and debugger). > browser is scrollable though, unlike during debugging sessions (which I > suppose can be expected since scroll events are probably DOM and js events). > not sure about this condition. maybe js cuts itself off from the world if > the syntax is bad enough "I throw up my hands" type of thing? :-) > some of my function calls were missing newly added arguments, etc.
On Sunday, January 13, 2013 11:45:46 PM UTC-8, Jim Michaels wrote:
> scrolling down in a .js file is very hard. jumps and flickers a lot on my > really old and slow pentium 4 HT 2.8GHz (1 core 2 threads) on firefox 18.0.
> also, there is another problem where sometimes if the code syntax is bad > js won't execute it and the debugger won't kick out an error either. js and > debugger just give up. it just sits there (both browser and debugger). > browser is scrollable though, unlike during debugging sessions (which I > suppose can be expected since scroll events are probably DOM and js events). > not sure about this condition. maybe js cuts itself off from the world if > the syntax is bad enough "I throw up my hands" type of thing? :-) > some of my function calls were missing newly added arguments, etc.
I do not see any errors scrolling your script using FF 18.0 + FB 1.11.1 on Win7. My steps:
1. Opened Firebug on http://jesusnjim.com/common/js-stringtodtime.html 2. Enabled and switched to the *Script* panel 3. Reloaded the page 4. Chose *time-funcs.js* from the Script Location Menu 5. Scrolled up and down using the mouse wheel, the scrollbar and the Page Up/Down keys
So please install Firebug into a fresh Firefox profile and try it again. If you still see these problems, please provide clear steps how to reproduce them.
On Monday, January 14, 2013 9:40:24 AM UTC+1, Jim Michaels wrote:
> ...and sometimes the program counter/pointer disappears, I think when I > alt-tab to my editor to look at something.
> On Sunday, January 13, 2013 11:45:46 PM UTC-8, Jim Michaels wrote:
>> scrolling down in a .js file is very hard. jumps and flickers a lot on my >> really old and slow pentium 4 HT 2.8GHz (1 core 2 threads) on firefox 18.0.
>> also, there is another problem where sometimes if the code syntax is bad >> js won't execute it and the debugger won't kick out an error either. js and >> debugger just give up. it just sits there (both browser and debugger). >> browser is scrollable though, unlike during debugging sessions (which I >> suppose can be expected since scroll events are probably DOM and js events). >> not sure about this condition. maybe js cuts itself off from the world if >> the syntax is bad enough "I throw up my hands" type of thing? :-) >> some of my function calls were missing newly added arguments, etc.
On Monday, January 14, 2013 5:14:48 AM UTC-8, Sebastian Zartner wrote:
> I do not see any errors scrolling your script using FF 18.0 + FB 1.11.1 on > Win7. > My steps:
> 1. Opened Firebug on http://jesusnjim.com/common/js-stringtodtime.html > 2. Enabled and switched to the *Script* panel > 3. Reloaded the page > 4. Chose *time-funcs.js* from the Script Location Menu > 5. Scrolled up and down using the mouse wheel, the scrollbar and the Page > Up/Down keys
> So please install Firebug into a fresh Firefox profile and try it again. > If you still see these problems, please provide clear steps how to > reproduce them.
> Sebastian > On Monday, January 14, 2013 9:40:24 AM UTC+1, Jim Michaels wrote:
>> ...and sometimes the program counter/pointer disappears, I think when I >> alt-tab to my editor to look at something.
>> On Sunday, January 13, 2013 11:45:46 PM UTC-8, Jim Michaels wrote:
>>> scrolling down in a .js file is very hard. jumps and flickers a lot on >>> my really old and slow pentium 4 HT 2.8GHz (1 core 2 threads) on firefox >>> 18.0.
>>> also, there is another problem where sometimes if the code syntax is bad >>> js won't execute it and the debugger won't kick out an error either. js and >>> debugger just give up. it just sits there (both browser and debugger). >>> browser is scrollable though, unlike during debugging sessions (which I >>> suppose can be expected since scroll events are probably DOM and js events). >>> not sure about this condition. maybe js cuts itself off from the world >>> if the syntax is bad enough "I throw up my hands" type of thing? :-) >>> some of my function calls were missing newly added arguments, etc.
insert a space between min and 1. it will hang. this is my current problem and I can't understand why. I am not asking you to debug it. Iam simply asking for the debugger to work properly. debuggers are supposed to be able to take over when the browser or application would otherwise be unable to respond. that is one of the features of a debugger normally. that is one of the things that makes a debugger useful. the other issues I listed are also a problem.
On Monday, January 14, 2013 5:14:48 AM UTC-8, Sebastian Zartner wrote:
> I do not see any errors scrolling your script using FF 18.0 + FB 1.11.1 on > Win7. > My steps:
> 1. Opened Firebug on http://jesusnjim.com/common/js-stringtodtime.html > 2. Enabled and switched to the *Script* panel > 3. Reloaded the page > 4. Chose *time-funcs.js* from the Script Location Menu > 5. Scrolled up and down using the mouse wheel, the scrollbar and the Page > Up/Down keys
> So please install Firebug into a fresh Firefox profile and try it again. > If you still see these problems, please provide clear steps how to > reproduce them.
> Sebastian > On Monday, January 14, 2013 9:40:24 AM UTC+1, Jim Michaels wrote:
>> ...and sometimes the program counter/pointer disappears, I think when I >> alt-tab to my editor to look at something.
>> On Sunday, January 13, 2013 11:45:46 PM UTC-8, Jim Michaels wrote:
>>> scrolling down in a .js file is very hard. jumps and flickers a lot on >>> my really old and slow pentium 4 HT 2.8GHz (1 core 2 threads) on firefox >>> 18.0.
>>> also, there is another problem where sometimes if the code syntax is bad >>> js won't execute it and the debugger won't kick out an error either. js and >>> debugger just give up. it just sits there (both browser and debugger). >>> browser is scrollable though, unlike during debugging sessions (which I >>> suppose can be expected since scroll events are probably DOM and js events). >>> not sure about this condition. maybe js cuts itself off from the world >>> if the syntax is bad enough "I throw up my hands" type of thing? :-) >>> some of my function calls were missing newly added arguments, etc.
On Mon, Jan 14, 2013 at 8:10 PM, Jim Michaels <jmich...@yahoo.com> wrote:
> to be honest, I don't want to lose my 60 tabs.
If you have Options/General/Startup set to "Show my windows and tabs
from last time", you should be able to exit Firefox and have it
remember what you were doing.
Then start Firefox with /p to start in Profile Manager mode, Create a
new profile under a different name. Run Firefox using it. You'll
have a blank profile with a default install. Install Firebug and see
if you still have the problem. Your issue may not be with Firebug
itself. You may be seeing an interaction with another addon, or
simply a problem with Firefox itself being overloaded from *having* 60
tabs open.
We need to narrow down your issue and make sure it *is* Firebug that
has the problem, and a clean install in a new profile is the best way
to do that.
as usual, tried new and makes no difference. I already have a new profile anyway as of 2 months ago. so I am going back to my nice comfy 60 tabs profile. I am still debugging the code, I have taken a break on it for today. will upload for you to tinker with. dies on immediate load. sad to see. not sure how to fix it, but slowly seem to be making progress. the code allows for time calculations, especially easy addition and subtraction of different kinds of time as input in a string.
On Monday, January 14, 2013 5:47:59 PM UTC-8, dmccunney wrote:
> On Mon, Jan 14, 2013 at 8:10 PM, Jim Michaels <jmic...@yahoo.com<javascript:>> > wrote:
> > to be honest, I don't want to lose my 60 tabs.
> If you have Options/General/Startup set to "Show my windows and tabs > from last time", you should be able to exit Firefox and have it > remember what you were doing.
> Then start Firefox with /p to start in Profile Manager mode, Create a > new profile under a different name. Run Firefox using it. You'll > have a blank profile with a default install. Install Firebug and see > if you still have the problem. Your issue may not be with Firebug > itself. You may be seeing an interaction with another addon, or > simply a problem with Firefox itself being overloaded from *having* 60 > tabs open.
> We need to narrow down your issue and make sure it *is* Firebug that > has the problem, and a clean install in a new profile is the best way > to do that.
> Once you've gone through that exercise, you can run firefox /p and > select your original profile, and get your 60 tabs back, > ______ > Dennis > https://plus.google.com/u/0/105128793974319004519
> as usual, tried new and makes no difference. I already have a new profile > anyway as of 2 months ago.
Doesn't sound like it's new. :-) As Dennis already explained very detailed (thanks for that!) testing your case on a fresh profile is the first step in isolating the problem. So if you want us to fix the issue, please follow all steps at https://getfirebug.com/firstaid.
so I am going back to my nice comfy 60 tabs profile. I am still debugging
> the code, I have taken a break on it for today. will upload for you to > tinker with. dies on immediate load. sad to see. not sure how to fix it, > but slowly seem to be making progress.
If you can reduce your test case to a few clear steps like I wrote them before, I'll have a look at it.
On Wed, Jan 16, 2013 at 1:40 PM, Sebastian Zartner
<sebastianzart...@gmail.com> wrote:
> As Dennis already explained very detailed (thanks for that!) testing your case on a fresh profile
> is the first step in isolating the problem.
<chuckle> That was the short form, presuming some knowledge on the
part of the user. The long form is a lot more detailed.
I play with profiles all the time. One bit about Profile Manager that
gets overlooked is that you can specify *where* the profile is
created. I'm not thrilled with Mozilla's default location for
profiles under Windows, so I create mine under
\Mozilla\Profiles\Firefox\<profile name>. It makes fiddling easier.
I have a development profile with Firebug and other tools installed.
The standard profile doesn't need them.
The current fun is putting Firefox, the profile I'm using, and the
cache on a 128MB ramdisk, which speeds things up a treat on the
netbook I'm posting from at the moment. The profile directory and
firefox itself are stored in zip files in the profile directory. A
startup script unzips them to the ramdisk for use. A shutdown script
zips them back to the HD, catching any changes..
The desktop runs Ubuntu 12.04 LTS. The netbook runs WinXP Home. I run
a current Aurora build on both sides to compare performance. The
netbook is relatively limited - 1.6ghx Atom CPU/1.5GB RAM - and part
of the exercise is an Aurora config that runs decently on the limited
hardware. Among other things, Aurora seems to be a lot more memory
efficient on Linux.
(I can't imagine 60 open tabs on the netbook: I'd grow old and grey
waiting for them all to load, and RAM requirements would balloon. It
might work on the desktop, but nothing I normally do requires that
many tabs to be open at once.)
I did try on a new profile and it makes no difference. despite 2 requests for this. the problems still exist. I am having problems debugging right now because while I am debugging, the debugger code area will go pure blank white and unclickable. randomly while I scroll. hitting the step into button seems to make the code reappear again.
On Wednesday, January 16, 2013 10:40:31 AM UTC-8, Sebastian Zartner wrote:
> as usual, tried new and makes no difference. I already have a new profile >> anyway as of 2 months ago.
> Doesn't sound like it's new. :-) As Dennis already explained very detailed > (thanks for that!) testing your case on a fresh profile is the first step > in isolating the problem. > So if you want us to fix the issue, please follow all steps at > https://getfirebug.com/firstaid.
> so I am going back to my nice comfy 60 tabs profile. I am still debugging >> the code, I have taken a break on it for today. will upload for you to >> tinker with. dies on immediate load. sad to see. not sure how to fix it, >> but slowly seem to be making progress.
> If you can reduce your test case to a few clear steps like I wrote them > before, I'll have a look at it.
On Mon, Jan 28, 2013 at 6:36 PM, Jim Michaels <jmich...@yahoo.com> wrote:
> I did try on a new profile and it makes no difference. despite 2 requests
> for this. the problems still exist.
> I am having problems debugging right now because while I am debugging, the
> debugger code area will go pure blank white and unclickable. randomly while
> I scroll. hitting the step into button seems to make the code reappear
> again.
What are the specs on the machine you are using? (Machine, OS,
video...particularly video.)
Among other things, FF is at the mercy of your hardware. Current
versions of FF (and Chrome) attempt to use hardware acceleration where
available to boost performance. This can bite, especially in video,
if you have an unsupported chipset or don't have the most recent
drivers.
In Options/Advanced/General, is "Use hardware acceleration when
available" checked? If it is, what happens if you turn it off and
restart Firefox? If it's not checked, what happens if you turn it on
and restart? Your problem sounds like a display problem affected by
this.
I had problems a while back where FF would lock the machine up and
require a hardware reset to get it back, with the same issues under
Windows and Linux. The problems went away when I switched
motherboards from one using a VIA chipset and onboard s3 video to one
using Intel graphics.
______
Dennis
https://plus.google.com/u/0/105128793974319004519
xp pro sp3 32-bit 3GB RAM, 38GB virtualmemory 32-bit pentium 4 HT (1 core 2-thread) 2.8GHz disk free space (* is next to windows drive): C:---------------------------------******* 178.79GB/ 896.18GB( 19.95%) D:-----------------*********************** 1.18TB/ 2.00TB( 59.07%) *E:-----------------------------------***** 145.95GB/ 1.00TB( 14.53%) F:-----------------------***************** 3.38GB/ 7.75GB( 43.67%) G:------------------------**************** 3.14GB/ 7.51GB( 41.90%) H:------------------------**************** 3.20GB/ 7.56GB( 42.33%) I:-----------------------***************** 3.44GB/ 7.80GB( 44.07%) J:-----------------------***************** 3.33GB/ 7.69GB( 43.28%) K:-----------------------***************** 3.44GB/ 7.81GB( 44.10%) L:-----------------------***************** 3.28GB/ 7.66GB( 42.89%) M:--------------------------************** 2.91GB/ 8.01GB( 36.41%) TOT:-------------------------*************** 1.53TB/ 3.96TB( 38.67%) TOT USED:----------------************************ 2.43TB/ 3.96TB( 61.33%) firefox 18.0.1 firebug 1.11.1 about:support contains: Application Basics Name Firefox Version 18.0.1 User Agent Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0 Profile Folder Enabled Plugins about:plugins Build Configuration about:buildconfig Crash Reports about:crashes Memory Use about:memory Extensions Name Version Enabled ID Adobe BrowserLab for Firebug 1.0.0.1227P.314153 true Adobe Contribute Toolbar 6.0 true {01A8CA0A-4C96-465b-A49B-65C46FAD54F9} DownThemAll! 2.0.15 true {DDC359D1-844A-42a7-9AA1-88A850A938A8} Feedback 1.2.2 true Firebug 1.11.1 true HP Detect 1.0.19.2 true {ab91efd4-6975-4081-8552-1b3922ed79e2} Norton Toolbar 2013.2.4.2 true {2D3F3651-74B9-4795-BDEC-6DA2F431CB62} Places Maintenance 1.3 true RSS Icon In Awesombar 1.4 true HP Smart Web Printing 4.60 false Microsoft .NET Framework Assistant 0.0.0 false {20a82645-c095-46ed-80e3-08825760534b} Norton Vulnerability Protection 11.1.1.5 - 2 false {BBDA0591-3099-440a-AA10-41764D9DB4DB} Important Modified Preferences Name Value accessibility.typeaheadfind.flashBar 0 browser.cache.disk.capacity 358400 browser.cache.disk.smart_size.first_run false browser.cache.disk.smart_size.use_old_max false browser.cache.disk.smart_size_cached_value 358400 browser.places.smartBookmarksVersion 4 browser.search.useDBForOrder true browser.startup.homepage about:blank browser.startup.homepage_override.buildID 20130116073211 browser.startup.homepage_override.mstone 18.0.1 extensions.lastAppVersion 18.0.1 keyword.URL http://search.yahoo.com/search?fr=mcafee&p= network.cookie.prefsMigrated true places.database.lastMaintenance 1359097612 places.history.expiration.transient_current_max_pages 80504 privacy.clearOnShutdown.cache false privacy.clearOnShutdown.cookies false privacy.clearOnShutdown.downloads false privacy.clearOnShutdown.history false privacy.clearOnShutdown.passwords true privacy.sanitize.migrateFx3Prefs true privacy.sanitize.promptOnSanitize true security.warn_viewing_mixed false Graphics Adapter Description NVIDIA GeForce 6200 Adapter Drivers nv4_disp Adapter RAM Unknown Device ID 0x0221 Direct2D Enabled no information DirectWrite Enabled false (0.0.0.0) Driver Date 1-3-2013 Driver Version 6.14.13.774 GPU #2 Active false GPU Accelerated Windows 1/1 Direct3D 9 Vendor ID 0x10de WebGL Renderer Google Inc. -- ANGLE (NVIDIA GeForce 6200 ) AzureCanvasBackend cairo AzureContentBackend none AzureFallbackCanvasBackend none JavaScript Incremental GC true Accessibility Activated false Prevent Accessibility 0 Library Versions Expected minimum version Version in use NSPR 4.9.4 4.9.4 NSS 3.14.1.0 Basic ECC 3.14.1.0 Basic ECC NSSSMIME 3.14.1.0 Basic ECC 3.14.1.0 Basic ECC NSSSSL 3.14.1.0 Basic ECC 3.14.1.0 Basic ECC NSSUTIL 3.14.1.0 3.14.1.0
because there was no difference in behavior between new profile I tried about last week and my existing nicely decorated profile, I have reverted back to my nice comfortable old profile. this is what you see above.
mozilla said they are leaning toward doing away with firefox -p in favor of a profile reset button in about:support.
about:support for new profile:
Application Basics
Name Firefox
Version 18.0.1
User Agent Mozilla/5.0 (Windows NT 5.1; rv:18.0) Gecko/20100101 Firefox/18.0
On Sunday, January 13, 2013 11:45:46 PM UTC-8, Jim Michaels wrote:
> scrolling down in a .js file is very hard. jumps and flickers a lot on my > really old and slow pentium 4 HT 2.8GHz (1 core 2 threads) on firefox 18.0.
> also, there is another problem where sometimes if the code syntax is bad > js won't execute it and the debugger won't kick out an error either. js and > debugger just give up. it just sits there (both browser and debugger). > browser is scrollable though, unlike during debugging sessions (which I > suppose can be expected since scroll events are probably DOM and js events). > not sure about this condition. maybe js cuts itself off from the world if > the syntax is bad enough "I throw up my hands" type of thing? :-) > some of my function calls were missing newly added arguments, etc.
For solving Firebug issues it's required to test them on a fresh, new profile. The info you provided obviously shows that there are other extensions installed. So please create a new profile as described at https://getfirebug.com/wiki/index.php/Install_Firebug_into_a_clean_pr... try your steps again.
Jim, I know you want your issues to be fixed. Therefore we need your help. Unforunately you never made it easy for us to help you. So please consider these three points from now on:
You described three or four different issues you see in this thread. The initial topic was about the scrolling not working properly inside the Script panel. So let's limit this discussion to that from now on. Create other threads for the other problems you see and also follow the three steps above for them.
bug:scroll thumb movement and scroll buttons cause viewport whiteout -------------------------------------------------------------------- new profile using firefox -p makes no difference. fb 1.11.1 Pentium 4 HT 2.8GHz (1 core 2 thread) firefox 18.0.1 XP Pro SP3 32-bit 3GB RAM, 38GB VM 2x2TB hard disks
disk free space (* next to drive is current/windows drive) Tue 01/29/2013 19:23:50.81||E:\|>\u\df * -a C:---------------------------------******* 178.79GB/ 896.18GB( 19.95%) D:-----------------*********************** 1.18TB/ 2.00TB( 59.07%) *E:-----------------------------------***** 145.93GB/ 1.00TB( 14.52%) F:-----------------------***************** 3.38GB/ 7.75GB( 43.67%) G:------------------------**************** 3.14GB/ 7.51GB( 41.90%) H:------------------------**************** 3.20GB/ 7.56GB( 42.33%) I:-----------------------***************** 3.44GB/ 7.80GB( 44.07%) J:-----------------------***************** 3.33GB/ 7.69GB( 43.28%) K:-----------------------***************** 3.44GB/ 7.81GB( 44.10%) L:-----------------------***************** 3.28GB/ 7.66GB( 42.89%) M:--------------------------************** 2.91GB/ 8.01GB( 36.41%) TOT:-------------------------*************** 1.53TB/ 3.96TB( 38.67%) TOT USED:----------------************************ 2.43TB/ 3.96TB( 61.33%) the small partitions are for swap/VM. 32-bit system has limit of 4GiB swap chunks, but you can have lots of them.
3 times I have said I have tried in a new profile about last week with no change in behavior to different people on this thread. nobody is listening. I know how to use firefox -p.
look in earlier post for test cases with clear instructions. I just don't understand why fb 1.11.1 works for you guys and not for me no matter what I try - technician-at-the-helm syndrome probably.
I was just discussing the problem, and it MIGHT be: - the slowness of my machine. Pentium 4 HT 2.8GHz (1 core 2 thread). it's equivalent to today's cheapest $300 laptop. really bad. I am used to it, but sometimes it seems really slow. - my platform or OS. I have XP Pro SP3 32-bit
I would ask that you please try doing your testing on a really slow box like an old P4 xp machine. you might be able to repro the results. I have had similar troubles with fb before on this platform. this is all I have right now for a platform. I can also try on a windows 8 p4 box.
test case:
1.just updated (and fixed, to all appearances) my javascript code visit http://Jesusnjim.com/test/js-stringtodtime.html 2.turn on debugger 3.enable all panels 4.reload 5.view the script time-funcs.js and hold down the scroll thumb (the little block) and scroll slowly. this code is about 2k lines of code. it should cause fb to sporadically make the code viewer go completely white. you can also try viewing jquery's source. 6.go to function NamedTimeStringToDTime and put breakpoints on every instance of GetIntegerKeywordPair() and StringDateTimeToDTime(). 174, 978, 1850,1851,1882,1883, 1937,1945,1949,1956,1958,1967,1975,1979,1989,1997, 2012,2020,2024,2043, 7.hit the refresh button on the browser. this will get the code going. 8. move the mouse over to the first breakpoint right over the yellow program pointer. this usually causes code viewer to go white. 9. click the scroll thumb the little box in the center of the scroll, and drag slowly up and down. this may or may not cause code viewport to go white. it sometimes causes code to incompletely render, with whited out block at bottom depending on down speed.
expected: complete rendering of code
actual: dragging thumb slowly up and down may or may not cause code viewport to go white. it sometimes causes code to incompletely render, with whited out block at bottom depending on down speed.
> For solving Firebug issues it's required to test them on a fresh, new > profile. The info you provided obviously shows that there are other > extensions installed. So please create a new profile as described at > https://getfirebug.com/wiki/index.php/Install_Firebug_into_a_clean_pr... try your steps again.
> Jim, I know you want your issues to be fixed. Therefore we need your help. > Unforunately you never made it easy for us to help you. So please consider > these three points from now on:
> You described three or four different issues you see in this thread. The > initial topic was about the scrolling not working properly inside the > Script panel. So let's limit this discussion to that from now on. Create > other threads for the other problems you see and also follow the three > steps above for them.
I tried to reproduce your steps on FF 18.0.1 + FB 1.11.1 on Win8 and I still can't reproduce your issue.
6.go to function NamedTimeStringToDTime and put breakpoints on every
> instance of GetIntegerKeywordPair() and StringDateTimeToDTime(). 174, 978, > 1850,1851,1882,1883, 1937,1945,1949,1956,1958,1967,1975,1979,1989,1997, > 2012,2020,2024,2043,
I assume these numbers should be the line numbers of the calls to GetIntegerKeywordPair() and StringDateTimeToDTime(). Though the only calls to these functions are in line 1920, 1940, 1970, 1992 and 2015.
Anyway, I assume your problem doesn't lie in the slowness of your PC but may be caused by problems related to your graphics card. So please turn off hardware acceleration by unchecking *Tools > Options > Advanced > General > Use hardware acceleration when available*. Does the problem go away? If not, please update your graphics card driver and try it again with and without that option being checked.
I am sure I said to please try to reproduce on a 32-bit XP box. I am sure your nice fast 64-bit environment works wonderfully. on my slow 32-bit box, things don't work well. this is what I am having trouble on. I will give it a go on my 32-bit 8 box now that I can upload and try again. I am having similar problems on everything I try to debug. I am pulling hair out trying to fix bugs with fb.
one of the problems is when it gets to a return statement, instead of putting the program pointer there, it skips over it and jumps somewhere else. PLEASE try on a 32-bit xp box.
On Tuesday, February 5, 2013 2:43:38 PM UTC-8, Sebastian Zartner wrote:
> I tried to reproduce your steps on FF 18.0.1 + FB 1.11.1 on Win8 and I > still can't reproduce your issue.
> 6.go to function NamedTimeStringToDTime and put breakpoints on every >> instance of GetIntegerKeywordPair() and StringDateTimeToDTime(). 174, 978, >> 1850,1851,1882,1883, 1937,1945,1949,1956,1958,1967,1975,1979,1989,1997, >> 2012,2020,2024,2043,
> I assume these numbers should be the line numbers of the calls to > GetIntegerKeywordPair() and StringDateTimeToDTime(). Though the only > calls to these functions are in line 1920, 1940, 1970, 1992 and 2015.
> Anyway, I assume your problem doesn't lie in the slowness of your PC but > may be caused by problems related to your graphics card. So please turn off > hardware acceleration by unchecking *Tools > Options > Advanced > General > > Use hardware acceleration when available*. Does the problem go away? If > not, please update your graphics card driver and try it again with and > without that option being checked.
I do not have a system with a 32-bit processor anymore. Though I tried it on an old Athlon 64 X2 with WinXP 32-bit and I still don't see your problem. I.e. the Script panel never turns white. So could you please try out the things I mentioned in my last comment?
Anyway, as I already wrote in your other thread<https://groups.google.com/forum/#!topic/firebug/SoxxkXYeDoU>we'll soon move to a new display (the same one the integrated dev tools use) for the Script panel. So this problem will probably be gone then.
On Friday, February 8, 2013 9:08:32 AM UTC+1, Jim Michaels wrote:
> I am sure I said to please try to reproduce on a 32-bit XP box. I am sure > your nice fast 64-bit environment works wonderfully. on my slow 32-bit > box, things don't work well. > this is what I am having trouble on. I will give it a go on my 32-bit 8 > box now that I can upload and try again. I am having similar problems on > everything I try to debug. I am pulling hair out trying to fix bugs with > fb.
> one of the problems is when it gets to a return statement, instead of > putting the program pointer there, it skips over it and jumps somewhere > else. PLEASE try on a 32-bit xp box.
> On Tuesday, February 5, 2013 2:43:38 PM UTC-8, Sebastian Zartner wrote:
>> I tried to reproduce your steps on FF 18.0.1 + FB 1.11.1 on Win8 and I >> still can't reproduce your issue.
>> 6.go to function NamedTimeStringToDTime and put breakpoints on every >>> instance of GetIntegerKeywordPair() and StringDateTimeToDTime(). 174, 978, >>> 1850,1851,1882,1883, 1937,1945,1949,1956,1958,1967,1975,1979,1989,1997, >>> 2012,2020,2024,2043,
>> I assume these numbers should be the line numbers of the calls to >> GetIntegerKeywordPair() and StringDateTimeToDTime(). Though the only >> calls to these functions are in line 1920, 1940, 1970, 1992 and 2015.
>> Anyway, I assume your problem doesn't lie in the slowness of your PC but >> may be caused by problems related to your graphics card. So please turn off >> hardware acceleration by unchecking *Tools > Options > Advanced > >> General > Use hardware acceleration when available*. Does the problem go >> away? If not, please update your graphics card driver and try it again with >> and without that option being checked.
some of the problems with scrolling seemed to go away when I reset my profile using about:support. but all the rest of the problems (caching, error lines consistently reported wrong, etc) aree still there. interesting. basically, I got tired of the issues, and just decided to scrap everything and start over after backing up my bookmarks. I lost my plugins, and everything. so it's like starting over from scratch with fresh new firefox.
On Tuesday, February 5, 2013 2:43:38 PM UTC-8, Sebastian Zartner wrote:
> I tried to reproduce your steps on FF 18.0.1 + FB 1.11.1 on Win8 and I > still can't reproduce your issue.
> 6.go to function NamedTimeStringToDTime and put breakpoints on every >> instance of GetIntegerKeywordPair() and StringDateTimeToDTime(). 174, 978, >> 1850,1851,1882,1883, 1937,1945,1949,1956,1958,1967,1975,1979,1989,1997, >> 2012,2020,2024,2043,
> I assume these numbers should be the line numbers of the calls to > GetIntegerKeywordPair() and StringDateTimeToDTime(). Though the only > calls to these functions are in line 1920, 1940, 1970, 1992 and 2015.
> Anyway, I assume your problem doesn't lie in the slowness of your PC but > may be caused by problems related to your graphics card. So please turn off > hardware acceleration by unchecking *Tools > Options > Advanced > General > > Use hardware acceleration when available*. Does the problem go away? If > not, please update your graphics card driver and try it again with and > without that option being checked.
On Sunday, February 10, 2013 2:13:04 PM UTC-8, Jim Michaels wrote:
> some of the problems with scrolling seemed to go away when I reset my > profile using about:support. but all the rest of the problems (caching, > error lines consistently reported wrong, etc) aree still there. > interesting. basically, I got tired of the issues, and just decided to > scrap everything and start over after backing up my bookmarks. > I lost my plugins, and everything. so it's like starting over from scratch > with fresh new firefox.
> On Tuesday, February 5, 2013 2:43:38 PM UTC-8, Sebastian Zartner wrote:
>> I tried to reproduce your steps on FF 18.0.1 + FB 1.11.1 on Win8 and I >> still can't reproduce your issue.
>> 6.go to function NamedTimeStringToDTime and put breakpoints on every >>> instance of GetIntegerKeywordPair() and StringDateTimeToDTime(). 174, 978, >>> 1850,1851,1882,1883, 1937,1945,1949,1956,1958,1967,1975,1979,1989,1997, >>> 2012,2020,2024,2043,
>> I assume these numbers should be the line numbers of the calls to >> GetIntegerKeywordPair() and StringDateTimeToDTime(). Though the only >> calls to these functions are in line 1920, 1940, 1970, 1992 and 2015.
>> Anyway, I assume your problem doesn't lie in the slowness of your PC but >> may be caused by problems related to your graphics card. So please turn off >> hardware acceleration by unchecking *Tools > Options > Advanced > >> General > Use hardware acceleration when available*. Does the problem go >> away? If not, please update your graphics card driver and try it again with >> and without that option being checked.
On Monday, February 11, 2013 12:47:39 AM UTC+1, Jim Michaels wrote:
> the "cache" problem was me not ftp'ing my code like I should. :-/ agh. > the error lines was really weird. > got my group calendar working now.
> On Sunday, February 10, 2013 2:13:04 PM UTC-8, Jim Michaels wrote:
>> some of the problems with scrolling seemed to go away when I reset my >> profile using about:support. but all the rest of the problems (caching, >> error lines consistently reported wrong, etc) aree still there. >> interesting. basically, I got tired of the issues, and just decided to >> scrap everything and start over after backing up my bookmarks. >> I lost my plugins, and everything. so it's like starting over from >> scratch with fresh new firefox.
>> On Tuesday, February 5, 2013 2:43:38 PM UTC-8, Sebastian Zartner wrote:
>>> I tried to reproduce your steps on FF 18.0.1 + FB 1.11.1 on Win8 and I >>> still can't reproduce your issue.
>>> 6.go to function NamedTimeStringToDTime and put breakpoints on every >>>> instance of GetIntegerKeywordPair() and StringDateTimeToDTime(). 174, 978, >>>> 1850,1851,1882,1883, 1937,1945,1949,1956,1958,1967,1975,1979,1989,1997, >>>> 2012,2020,2024,2043,
>>> I assume these numbers should be the line numbers of the calls to >>> GetIntegerKeywordPair() and StringDateTimeToDTime(). Though the only >>> calls to these functions are in line 1920, 1940, 1970, 1992 and 2015.
>>> Anyway, I assume your problem doesn't lie in the slowness of your PC but >>> may be caused by problems related to your graphics card. So please turn off >>> hardware acceleration by unchecking *Tools > Options > Advanced > >>> General > Use hardware acceleration when available*. Does the problem >>> go away? If not, please update your graphics card driver and try it again >>> with and without that option being checked.
On Monday, February 11, 2013 8:46:22 AM UTC+1, Sebastian Zartner wrote:
> Sounds like everything is working now. Congratulations!
> Sebastian
> On Monday, February 11, 2013 12:47:39 AM UTC+1, Jim Michaels wrote:
>> the "cache" problem was me not ftp'ing my code like I should. :-/ agh. >> the error lines was really weird. >> got my group calendar working now.
>> On Sunday, February 10, 2013 2:13:04 PM UTC-8, Jim Michaels wrote:
>>> some of the problems with scrolling seemed to go away when I reset my >>> profile using about:support. but all the rest of the problems (caching, >>> error lines consistently reported wrong, etc) aree still there. >>> interesting. basically, I got tired of the issues, and just decided to >>> scrap everything and start over after backing up my bookmarks. >>> I lost my plugins, and everything. so it's like starting over from >>> scratch with fresh new firefox.
>>> On Tuesday, February 5, 2013 2:43:38 PM UTC-8, Sebastian Zartner wrote:
>>>> I tried to reproduce your steps on FF 18.0.1 + FB 1.11.1 on Win8 and I >>>> still can't reproduce your issue.
>>>> 6.go to function NamedTimeStringToDTime and put breakpoints on every >>>>> instance of GetIntegerKeywordPair() and StringDateTimeToDTime(). 174, 978, >>>>> 1850,1851,1882,1883, 1937,1945,1949,1956,1958,1967,1975,1979,1989,1997, >>>>> 2012,2020,2024,2043,
>>>> I assume these numbers should be the line numbers of the calls to >>>> GetIntegerKeywordPair() and StringDateTimeToDTime(). Though the only >>>> calls to these functions are in line 1920, 1940, 1970, 1992 and 2015.
>>>> Anyway, I assume your problem doesn't lie in the slowness of your PC >>>> but may be caused by problems related to your graphics card. So please turn >>>> off hardware acceleration by unchecking *Tools > Options > Advanced > >>>> General > Use hardware acceleration when available*. Does the problem >>>> go away? If not, please update your graphics card driver and try it again >>>> with and without that option being checked.
