Build ID: Mozilla/5.0 (Windows NT 6.1; rv:2.0b10pre) Gecko/20110120 Firefox/4.0b10pre Behavior: 1. Open the web console 2. Navigate https://spreadsheets.google.com/ccc?key=0AlsgObMBZ381dDREUTB2bVRhOGszcFNrYkgyYlhWTkE&hl=en#gid=0 (this is an example which throws many parser errors in console) 3. wait for the console to be done with echoing the errors and net events ========================================================================== Notice how fast errors are thrown in the console. This is not happening in Safari, and it's annoying, you can't follow up with the log. this can be also noticed more easily on mac os x. Due to this fast throwing, scrollbar can't follow up with the huge amount of data in the console and is delayed. =========================================================================== Suggestions: This is kind of trivial, but messes up the esthetics. We can just slow down a little and insert some delay() or wait() between echoed parsing errors, even if it will take longer to have all messages echoed. If we don't want delays at all, and want everything to be fast as it is, then we should find a way to sync the scrollbar with the logging area in these situations.

Safari's Web Inspector doesn't show the numerous CSS errors/warnings that the Web Console does. The problem at hand, I believe, can only be solved by coalescing the calls to scrollToVisible(), eg. every 100-500ms. In that time, any call to scrollToVisible() is moot - only the last call to the function would be executed when the delay is elapsed. This would perhaps complicate things, but scrolling would no longer be annoying when lots of errors are trying to show up at once. Thoughts?

while playing with one of the console storage bugs, I noticed that scrolling was introducing pretty severe performance problems with the console. Populating a console with a long list of messages (see CNN or Yahoo) would take several seconds to complete. Disabling scrolling would cut that time down to a more acceptable fraction of a second. I think whatever we do, we should keep that in mind. I'd like to maybe implement jump-scrolling where we move the scrollbar a half or full page at a time and fill up the visible space.

(In reply to comment #2) > while playing with one of the console storage bugs, I noticed that scrolling > was introducing pretty severe performance problems with the console. Populating > a console with a long list of messages (see CNN or Yahoo) would take several > seconds to complete. Disabling scrolling would cut that time down to a more > acceptable fraction of a second. Not sure, but the richlistbox may have made things slower to scroll... > I think whatever we do, we should keep that in mind. I'd like to maybe > implement jump-scrolling where we move the scrollbar a half or full page at a > time and fill up the visible space. Yeah, that would pretty much be the effect of coalescing. It would jump-scroll more pixels, depending on the amount of incoming messages within the given delay.

yes, but the effect would be different. With jump-scrolling like it's implemented in both terminals, we'd have an empty space filling the visible screen area that would get populated with new entries. When it fills, we scroll past the end of the container and start filling again. This would probably mean adding a bunch of empty elements to the container and scrolling to the bottom and replacing those elements with new items (or inserting before them and pushing them down below the edge of the visible scroll area, they could just stick around).

triage. Filter on PINKISBEAUTIFUL

Not touched in the past 5 years, and the console mechanism has changed greatly in the meantime.