User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 Build ID: 20170912100139 Steps to reproduce: There is around 30% CPU usage when using two fingers gesture to scroll through downloaded items in Library - Downloads Panel. This leads to very choppy scrolling and poor user experience. I have 42 items visible in Downloads Panel. Using mouse whell or using scrollbar is perfectly fine and smooth. My CPU is Intel Core i3 4030U 1.9Ghz with 2 Cores and 4 Threads.

[Tracking Requested - why for this release]:

Actually this is also affecting scrolling in Bookmarks list and History list in the Library panel. CPU usage spiking up to 40% and GPU usage up to 5-6%. While using scrollbar the CPU usage is below 10% and GPU usage 0%. Note: Scrolling in the Library/Downloads window using gesture is smooth.

Hello Eddward - would you be able to help us by gathering a performance profile when this problem occurs? Instructions for doing so are at https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem

Hope I did it right and will be helpful. https://perfht.ml/2x3lPVm

Hey Eddward, would you mind posting your about:support for the profile that you're experiencing this in?

Application Basics ------------------ Name: Firefox Version: 57.0a1 Build ID: 20170915100121 Update Channel: nightly User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 OS: Windows_NT 10.0 Multiprocess Windows: 1/1 (Enabled by default) Web Content Processes: 1/4 Stylo: true (enabled by default) Google Key: Found Mozilla Location Service Key: Found Safe Mode: false Crash Reports for the Last 3 Days --------------------------------- All Crash Reports Nightly Features ---------------- Name: Activity Stream Version: 2017.09.14.1322-706b3303 ID: activity-stream@mozilla.org Name: Application Update Service Helper Version: 2.0 ID: aushelper@mozilla.org Name: Click-to-Play staged rollout Version: 1.3 ID: clicktoplay-rollout@mozilla.org Name: Firefox Screenshots Version: 16.1.0 ID: screenshots@mozilla.org Name: FlyWeb Version: 1.0.0 ID: flyweb@mozilla.org Name: Follow-on Search Telemetry Version: 0.9.3 ID: followonsearch@mozilla.com Name: Form Autofill Version: 1.0 ID: formautofill@mozilla.org Name: Multi-process staged rollout Version: 3.00 ID: e10srollout@mozilla.org Name: Photon onboarding Version: 0.1 ID: onboarding@mozilla.org Name: Pocket Version: 1.0.5 ID: firefox@getpocket.com Name: Presentation Version: 1.0.0 ID: presentation@mozilla.org Name: Shield Recipe Client Version: 73 ID: shield-recipe-client@mozilla.org Name: TLS 1.3 Compatibility Testing of Middleboxes Version: 2.0.0 ID: tls13-middlebox@mozilla.org Name: Web Compat Version: 1.1 ID: webcompat@mozilla.org Name: WebCompat Reporter Version: 1.0.0 ID: webcompat-reporter@mozilla.org Extensions ---------- Name: Gmail™ Notifier + Version: 0.3.0 Enabled: true ID: jid1-sqmEAwSoa3FZPc@jetpack Name: small-clock Version: 0.0.4 Enabled: true ID: @small-clock Name: Stylus Version: 1.1.4.1 Enabled: true ID: {7a7a4a92-a2a0-41d1-9fd7-1e92480d612d} Name: uBlock Origin Version: 1.14.8 Enabled: true ID: uBlock0@raymondhill.net Name: YouTube Best Video Downloader 2 Version: 7.73 Enabled: true ID: {170503FA-3349-4F17-BC86-001888A5C8E2} Name: Adblock Plus development build Version: 2.99.0.1838beta Enabled: false ID: {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} Name: Gecko Profiler Version: 0.17 Enabled: false ID: geckoprofiler@mozilla.com Name: HTTPS Everywhere Version: 2017.9.12.1337 Enabled: false ID: https-everywhere-eff-bill@eff.org Graphics -------- Features Compositing: Direct3D 11 (Advanced Layers) Asynchronous Pan/Zoom: wheel input enabled; scrollbar drag enabled; keyboard enabled; autoscroll enabled WebGL 1 Driver WSI Info: EGL_VENDOR: Google Inc. (adapter LUID: 0000000000013bd5) EGL_VERSION: 1.4 (ANGLE 2.1.0.dec065540d5f) EGL_EXTENSIONS: EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_d3d_texture_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_ANGLE_direct_composition EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_EXT_device_query EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture_nv12 EGL_ANGLE_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_EXTENSIONS(nullptr): EGL_EXT_client_extensions EGL_EXT_platform_base EGL_EXT_platform_device EGL_ANGLE_platform_angle EGL_ANGLE_platform_angle_d3d EGL_ANGLE_device_creation EGL_ANGLE_device_creation_d3d11 EGL_ANGLE_experimental_present_path EGL_KHR_client_get_all_proc_addresses WebGL 1 Driver Renderer: Google Inc. -- ANGLE (Intel(R) HD Graphics Family Direct3D11 vs_5_0 ps_5_0) WebGL 1 Driver Version: OpenGL ES 2.0 (ANGLE 2.1.0.dec065540d5f) WebGL 1 Driver Extensions: GL_ANGLE_depth_texture GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_lossy_etc_decode GL_ANGLE_pack_reverse_row_order GL_ANGLE_request_extension GL_ANGLE_robust_client_memory GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_CHROMIUM_bind_generates_resource GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_sync_query GL_EXT_blend_minmax GL_EXT_color_buffer_half_float GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers GL_EXT_frag_depth GL_EXT_map_buffer_range GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_sRGB GL_EXT_shader_texture_lod GL_EXT_texture_compression_dxt1 GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_EXT_texture_storage GL_EXT_unpack_subimage GL_KHR_debug GL_NV_EGL_stream_consumer_external GL_NV_fence GL_NV_pack_subimage GL_NV_pixel_buffer_object GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth32 GL_OES_element_index_uint GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_array_object WebGL 1 Extensions: ANGLE_instanced_arrays EXT_blend_minmax EXT_color_buffer_half_float EXT_frag_depth EXT_shader_texture_lod EXT_texture_filter_anisotropic EXT_disjoint_timer_query OES_element_index_uint OES_standard_derivatives OES_texture_float OES_texture_float_linear OES_texture_half_float OES_texture_half_float_linear OES_vertex_array_object WEBGL_color_buffer_float WEBGL_compressed_texture_s3tc WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_depth_texture WEBGL_draw_buffers WEBGL_lose_context MOZ_WEBGL_lose_context MOZ_WEBGL_compressed_texture_s3tc MOZ_WEBGL_depth_texture WebGL 2 Driver WSI Info: EGL_VENDOR: Google Inc. (adapter LUID: 0000000000013bd5) EGL_VERSION: 1.4 (ANGLE 2.1.0.dec065540d5f) EGL_EXTENSIONS: EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_d3d_texture_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_ANGLE_direct_composition EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_EXT_device_query EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture_nv12 EGL_ANGLE_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_EXTENSIONS(nullptr): EGL_EXT_client_extensions EGL_EXT_platform_base EGL_EXT_platform_device EGL_ANGLE_platform_angle EGL_ANGLE_platform_angle_d3d EGL_ANGLE_device_creation EGL_ANGLE_device_creation_d3d11 EGL_ANGLE_experimental_present_path EGL_KHR_client_get_all_proc_addresses WebGL 2 Driver Renderer: Google Inc. -- ANGLE (Intel(R) HD Graphics Family Direct3D11 vs_5_0 ps_5_0) WebGL 2 Driver Version: OpenGL ES 3.0 (ANGLE 2.1.0.dec065540d5f) WebGL 2 Driver Extensions: GL_ANGLE_depth_texture GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_lossy_etc_decode GL_ANGLE_pack_reverse_row_order GL_ANGLE_request_extension GL_ANGLE_robust_client_memory GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_CHROMIUM_bind_generates_resource GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_sync_query GL_EXT_blend_minmax GL_EXT_color_buffer_float GL_EXT_color_buffer_half_float GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers GL_EXT_frag_depth GL_EXT_map_buffer_range GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_sRGB GL_EXT_shader_texture_lod GL_EXT_texture_compression_dxt1 GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_norm16 GL_EXT_texture_rg GL_EXT_texture_storage GL_EXT_unpack_subimage GL_KHR_debug GL_NV_EGL_stream_consumer_external GL_NV_fence GL_NV_pack_subimage GL_NV_pixel_buffer_object GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_EGL_image_external_essl3 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth32 GL_OES_element_index_uint GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_array_object WebGL 2 Extensions: EXT_color_buffer_float EXT_texture_filter_anisotropic EXT_disjoint_timer_query OES_texture_float_linear WEBGL_compressed_texture_s3tc WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_lose_context MOZ_WEBGL_lose_context MOZ_WEBGL_compressed_texture_s3tc Direct2D: true DirectWrite: true (10.0.16288.1) GPU #1 Active: Yes Description: Intel(R) HD Graphics Family Vendor ID: 0x8086 Device ID: 0x0a16 Driver Version: 20.19.15.4642 Driver Date: 3-28-2017 Drivers: igdumdim64 igd10iumd64 igd10iumd64 igd12umd64 igdumdim32 igd10iumd32 igd10iumd32 igd12umd32 Subsys ID: 397817aa RAM: Unknown Diagnostics AzureCanvasAccelerated: 0 AzureCanvasBackend: Direct2D 1.1 AzureCanvasBackend (UI Process): skia AzureContentBackend: Direct2D 1.1 AzureContentBackend (UI Process): skia AzureFallbackCanvasBackend (UI Process): cairo GPUProcessPid: 1984 GPUProcess: Terminate GPU Process Device Reset: Trigger Device Reset Decision Log WEBRENDER: opt-in by default: WebRender is an opt-in feature Media ----- Audio Backend: wasapi Max Channels: 2 Preferred Channel Layout: stereo Preferred Sample Rate: 48000 Output Devices Name: Group Speakers (Realtek High Definition Audio): HDAUDIO\FUNC_01&VEN_10EC&DEV_0233&SUBSYS_17AA3802&REV_1000\4&157dcdad&0&0001 Input Devices Name: Group Stereo Mix (Realtek High Definition Audio): HDAUDIO\FUNC_01&VEN_10EC&DEV_0233&SUBSYS_17AA3802&REV_1000\4&157dcdad&0&0001 Microphone (Realtek High Definition Audio): HDAUDIO\FUNC_01&VEN_10EC&DEV_0233&SUBSYS_17AA3802&REV_1000\4&157dcdad&0&0001 Microphone (Realtek High Definition Audio): HDAUDIO\FUNC_01&VEN_10EC&DEV_0233&SUBSYS_17AA3802&REV_1000\4&157dcdad&0&0001 Important Modified Preferences ------------------------------ accessibility.force_disabled: 1 accessibility.typeaheadfind.flashBar: 0 browser.cache.disk.capacity: 358400 browser.cache.disk.filesystem_reported: 1 browser.cache.disk.hashstats_reported: 1 browser.cache.disk.smart_size.first_run: false browser.cache.frecency_experiment: 3 browser.download.useDownloadDir: false browser.places.smartBookmarksVersion: 8 browser.sessionstore.upgradeBackup.latestBuildID: 20170915100121 browser.startup.homepage: https://www.google.sk/ browser.startup.homepage_override.buildID: 20170915100121 browser.startup.homepage_override.mstone: 57.0a1 browser.tabs.warnOnClose: false browser.urlbar.lastSuggestionsPromptDate: 20170823 browser.urlbar.timesBeforeHidingSuggestionsHint: 0 browser.urlbar.usepreloadedtopurls.enabled: false dom.forms.autocomplete.formautofill: true dom.push.userAgentID: 80110253c7c842de954ee0074809a265 extensions.lastAppVersion: 57.0a1 gfx.downloadable_fonts.otl_validation: false layers.mlgpu.sanity-test-failed: false media.benchmark.vp9.fps: 89 media.benchmark.vp9.versioncheck: 2 media.gmp-gmpopenh264.abi: x86_64-msvc-x64 media.gmp-gmpopenh264.lastUpdate: 1503958445 media.gmp-gmpopenh264.version: 1.6 media.gmp-manager.buildID: 20170915100121 media.gmp-manager.lastCheck: 1505486774 media.gmp-widevinecdm.abi: x86_64-msvc-x64 media.gmp-widevinecdm.lastUpdate: 1504240778 media.gmp-widevinecdm.version: 1.4.8.1008 media.gmp.storage.version.observed: 1 media.hardware-video-decoding.failed: false network.cookie.prefsMigrated: true network.predictor.cleaned-up: true places.database.lastMaintenance: 1504896520 places.history.expiration.transient_current_max_pages: 128773 plugin.disable_full_page_plugin_for_types: application/pdf plugins.ctprollout.cohort: excluded plugins.ctprollout.cohortSample: 0.482107 security.disable_button.openCertManager: false security.sandbox.content.tempDirSuffix: {b3c74412-48b0-410c-9e42-531b494a1cbe} security.ssl.errorReporting.automatic: true security.ssl3.rsa_des_ede3_sha: true services.sync.declinedEngines: services.sync.engine.addresses: true services.sync.engine.addresses.available: true services.sync.engine.bookmarks.validation.lastTime: 1505416292 services.sync.engine.prefs.modified: false services.sync.lastPing: 1505416239 services.sync.lastSync: Fri Sep 15 2017 19:51:35 GMT+0200 storage.vacuum.last.index: 1 storage.vacuum.last.places.sqlite: 1503533829 ui.osk.debug.keyboardDisplayReason: IKPOS: Touch screen not found. Important Locked Preferences ---------------------------- Places Database --------------- JavaScript ---------- Incremental GC: true Accessibility ------------- Activated: false Prevent Accessibility: 1 Accessible Handler Used: false Accessibility Instantiator: Library Versions ---------------- NSPR Expected minimum version: 4.17 Beta Version in use: 4.17 Beta NSS Expected minimum version: 3.33 Beta Version in use: 3.33 Beta NSSSMIME Expected minimum version: 3.33 Beta Version in use: 3.33 Beta NSSSSL Expected minimum version: 3.33 Beta Version in use: 3.33 Beta NSSUTIL Expected minimum version: 3.33 Beta Version in use: 3.33 Beta Experimental Features --------------------- Sandbox ------- Content Process Sandbox Level: 4 Effective Content Process Sandbox Level: 4

Thanks Eddward. So, lots of slow style flushes in the chrome process here... anything stand out to you as actionable, heycam?

Tracking as it seems to be an important perf regression.

Just FYI, disabling all WebExtension makes no difference. If you need more info let me know. Will respond as soon as possible.

Hey dholbert, anything actionable in that profile that got posted, styles-wise?

(That profile URL being: https://perfht.ml/2x3lPVm ) It looks like we are churning in a deeply-nested ElementRestyler::Restyle -> RestyleChildren -> RestyleContentChildren -> [etc] backtrace, and I *think* that usually means we're restyling some huge subtree, possibly the whole document (so, the full UI in this case). This usually means some style is getting applied/unapplied via e.g. new CSS rules being added, or probably things similar to that. One suspicious thing that stands out to me: I'm seeing us spending a sample (or a few) in WindowDeactivated -> WindowLowered and WindowActivated->WindowRaised, **just before each style flush**! This is precisely the sort of thing that would cause a full-browser restyle. Here's a profile link, zoomed in to part of the slow-restyle period, filtered for "ActivateOrDeactivate" (which catches both of these stacks): https://perfht.ml/2jEVQAA There's one spot in particular where you can see us *first* deactivate, and then activate, between two restyles! See the 2 samples matched in this profile (the first of which is "deactivate", the second of which is "activate"): https://perfht.ml/2jFguRj I suspect that sequence is happening between every refresh driver tick here, but only some of them are being caught by the profiler because the actual activate/deactivate action is very quick. So, I think the question is, why are we triggering a window deactivate/activate on every tick here?

Good questions, and good finds in there. I hadn't noticed the window activation / deactivation! Hey Eddward, would you be able to capture a screen recording of you reproducing the bug?

(In reply to Daniel Holbert [:dholbert] from comment #11) > So, I think the question is, why are we triggering a window > deactivate/activate on every tick here? Aren't panels implemented as 'windows' in some sense of the word (not in XUL, but at the lower OS levels)? Might that have something to do with it?

I'm unable to reproduce this issue on my Acer reference hardware, BTW. Details: - I'm using yesterday's 64-bit Windows nightly (2017-09-18), on Win10, with 40+ items visible in my downloads panel. - I tested by clicking on the "library" (|||\) icon on the toolbar, and then I clicked "Downloads", and then I scrolled up and down with two-finger scroll on my trackpad. (And I profiled just the two-finger scrolling section.) - Here's my profile (of me being unable to reproduce): https://perfht.ml/2xOKHUb -- this shows very little time spent in styling, and there are 0 hits for ActivateOrDeactivate. (And my experience is that the scrolling seems nice and smooth.) Eddward: I'm wondering if you might have some other system feature enabled, which makes two-finger gestures trigger some additional Windows function...? I'm trying to figure out why your window might be getting lowered/raised while you're scrolling, in a way that I can't reproduce locally. In any case, as Mike says, a screen recording would likely be helpful here. (In reply to :Gijs from comment #13) > Aren't panels implemented as 'windows' in some sense of the word (not in > XUL, but at the lower OS levels)? Might that have something to do with it? (That sounds right. And if so: yeah, that seems likely to have something to do with this...)

Uploading screencast. Well, I don't know about other system features which can interfere with this. Just usual stuff. Laptop is Lenovo M30. Touchpad device is Synaptics ClickPad V1.2, as far as I can see and all its Settings are by default.

It's 16MB file so have to upload somewhere else. http://s000.tinyupload.com/?file_id=41630284796087566951 Hope it works.

(In reply to Eddward from comment #15) > Uploading screencast. > Well, I don't know about other system features which can interfere with > this. Just usual stuff. Laptop is Lenovo M30. Touchpad device is Synaptics > ClickPad V1.2, as far as I can see and all its Settings are by default. I *think* I can repro on a Lenovo X230. https://perfht.ml/2xQcmnF :dholbert, is there something else I can do to debug? This is on a machine I use very occasionally to test behaviour relating to win8 and/or laptops with both touch screens and a 'real' keyboard builtin (as opposed to on-screen ones). I don't get a tray app for the touchpad and because this is win8 there's no "all programs". It doesn't show up when searching in the win8 "modern" UI either. So I expect it's basically default settings... If it's helpful, I could probably stick on a debug build made on my main win10 desktop and use msvc remote debugging to take a closer look, but I don't know what I'd be looking for...

(In reply to :Gijs from comment #17) > (In reply to Eddward from comment #15) > > Well, I don't know about other system features which can interfere with > > this. Just usual stuff. Laptop is Lenovo M30. Does your M30 have a touch-screen? (regardless of whether you're using that feature as part of the repro steps here) If so, maybe that's the relevant requirement, since Gijs's reproducing-friendly machine has a touchscreen as well... (In reply to :Gijs from comment #17) > :dholbert, is there something else I can do to debug? At this point I think we need to figure out: (1) why are we repeatedly de/re-activating our window while you scroll? (2) why does this only happen for this sort of panel, but not for other parts of the UI? We already have a backtrace of the frequent nsFocusManager::ActivateOrDeactivate calls, from the profiles here (e.g. https://perfht.ml/2xfvxqy from Gijs' profile), so we have *that part* of the "why". But I'm not sure that gives us enough info about where the signal is coming from. I'm hoping someone with windows widget knowledge -- maybe jimm -- can help out further here...

No, it's a Lenovo M30-70 without touch-screen.

Looks like this is triggering from nsWindow::DealWithPopups. I can't find line numbers in the profiler, if we have a system that reproduces, might be interesting to get a full stack to see where DealWithPopups triggers the focus change. That looks fishy to me.

(In reply to Jim Mathies [:jimm] from comment #20) > if we have a system that reproduces, might be interesting to get a full stack to see where DealWithPopups triggers the > focus change. That looks fishy to me. Gijs, maybe you could give this a try? (e.g. placing a breakpoint on nsFocusManager::ActivateOrDeactivate and seeing what the backtrace is, when it fires while you're scrolling)

Both of these from a self-built opt build, but hopefully still helpful.

Either of these stacks useful?

BTW, Gijs is pretty sure his build is from this cset: https://hg.mozilla.org/mozilla-central/rev/5f3f19824efa (In reply to Jim Mathies [:jimm] from comment #20) > might be interesting to get a full stack to see where DealWithPopups triggers the > focus change. That looks fishy to me. In both the Deactivate and Activate stacks, we seem to be in nsWindow::DealWithPopups at "Line 7985", which is the "return true" line here (but really we're probably inside the ::SetForegroundWindow just before it): 7980 case MOZ_WM_REACTIVATE: 7981 // The previous active window should take back focus. 7982 if (::IsWindow(reinterpret_cast<HWND>(aLParam))) { 7983 ::SetForegroundWindow(reinterpret_cast<HWND>(aLParam)); 7984 } 7985 return true; https://dxr.mozilla.org/mozilla-central/rev/5f3f19824efa/widget/windows/nsWindow.cpp#7985 So we're handling MOZ_WM_REACTIVATE, which is documented like so: 28 // If a popup window is being activated, we try to reactivate the previous 29 // window with this message. 30 #define MOZ_WM_REACTIVATE (WM_APP+0x0314) https://dxr.mozilla.org/mozilla-central/rev/5f3f19824efa/widget/windows/WinMessages.h#28-30 So it seems we think a popup window is "being activated", I guess? It looks like this MOZ_WM_REACTIVATE is only sent in one place, here: ::PostMessageW(aWnd, MOZ_WM_REACTIVATE, aWParam, aLParam); https://dxr.mozilla.org/mozilla-central/rev/5f3f19824efa/widget/windows/nsWindow.cpp#7935 jimm, does this make any sense to you? (Maybe the next step is to try and get a backtrace of that "PostMessageW(aWnd, MOZ_WM_REACTIVATE" call now)?

Masayuki, do you have cycles for this? Appears to be a bad interaction with a trackpad and our popup code in widget.

(Although, I don't understand "cycles" means in the previous comment.) The hack was added for old ASUS Zenbook's touchpad scroll. The touchpad was OEM of Synaptics but ASUS created custom utility. The utility made users allow to scroll window under cursor instead of focused window (the word "window" here is the term of Windows developers, a.k.a, "widget" or "control"). However, standard behavior of ~Window 8.1 (and Win10 without "Scroll inactive windows when I hover over them" in Settings of Mouse) is, wheel messages are always sent to focused window. So, the utility always tries to set focus to *any* window under mouse cursor. However, like popup style window of Gecko, applications don't assume that popup style window won't take focus. Therefore, the hack tried to take back focus to the owner window for handling following keyboard events, etc, normally. So, I guess that the touchpad utility for Thinkpad started to do such ugly hack and that causes ugly focus movement.

I wonder, why the popup panel needs to reflow something when it becomes active? I guess that it's autohide panel and it doesn't assume that activated event won't come during visible.

I also failed to reproduce this, this time on a Lenovo W540 ThinkPad (without touchscreen) which uses the Synaptics Pointing Device driver 19.0.17.115.

Could you please try safemode and see if it helps?

I would say it helped a bit, but still far from fluent "60fps" scrolling. CPU usage is still around 25% for the Nightly only.

https://www.notebookcheck.net/Lenovo-M30-70-Notebook-Review.121117.0.html Curious, is this the same laptop you're using Eddward?

(In reply to Jim Mathies [:jimm] from comment #32) > https://www.notebookcheck.net/Lenovo-M30-70-Notebook-Review.121117.0.html > > Curious, is this the same laptop you're using Eddward? Yes this is it. Only slightly faster CPU: Intel Core i3-4010U -> Intel Core i3-4030U and maybe different HDD (but still 500GB 5400rpm HDD).

Based on the fact that we haven't had anymore reports of this issue and we do not have an inhouse repro/nor a speculative fix, I am inclined to untrack and wontfix this for 57. If things change, please renominate for 57 tracking.

The most close configuration we have is a Acer Aspire V5 laptop, running Win 10 64-bit, with Intel Core i3-2377M, Synaptics PS/2 Port TouchPad Driver 19.1.3.6 and Touch support. On this device, scrolling on Library is not working at all (this may be a follow-up from bug 1345355) - see attachment. Gecko profiler: https://perfht.ml/2yiM76S Please let me know if there is anything else I can help with.

(In reply to Petruta Rasa [QA] [:petruta] from comment #35) > On this device, scrolling on Library is not working at all (this may be a > follow-up from bug 1345355) - see attachment. Hi Petruta -- this bug is actually about a different "Library" pane. Could you test again with the one shown in the reporter's screencast, from comment 36? (This bug is about submenus within the "||\" icon from the browser toolbar.) (The issue you mentioned about the other library sounds like a possibly-serious bug, too, though -- could you file a bug for that, to be sure that's tracked?)

Thanks for posting reporter's screencast. I see no obvious CPU increase when scrolling through Library panel (one time it reaches 10% but decreases fast) and the scrolling is not choppy. One buggy thing I notice is that scrolling up/down when the list already reached top/bottom will move the entire panel downwards/upwards.

I'm adding another screencast. This time with the Task Manager on the backgroud. It's not 100% accurate since screen recording consumes some power, but you'll get an idea. And by the way, the bug itself applies also to Library submenu in the main Hamburger menu. Also in "More" submenu / Text encoding. The effect is the same.

x64: https://queue.taskcluster.net/v1/task/QzxEQ87aTNKekZFgf5ks2A/runs/0/artifacts/public/build/target.zip x86: https://queue.taskcluster.net/v1/task/EMa8d0ufQgmmX-eEt8vcKg/runs/0/artifacts/public/build/target.zip I think that this is reproducible build of this bug even with any pointing device. Could you somebody check if it emulates this bug? If it does, I'll land it with a pref to enable this from another bug.

Yes, it still lags when scrolling. I thought it would have gotten traction and I would have just sat there waiting for a solution. Scrolling on the Add-Ons Manager also raises CPU a bit, but it's smooth. (Only to compare to the situation with the History list.) Going through the Library window, the CPU usage also goes up while scrolling but it is not bad nor choppy/laggy, like on the list. I could record to my phone and upload the video?

https://www.facebook.com/100009015086975/videos/1878761649100986/?l=4688885089017284970 I hope it shows enough.

I'm afraid your link is not working.

(In reply to Eddward from comment #43) > I'm afraid your link is not working. Yes, that's odd, Facebook said that the link should be enough to see the video for anyone even if they aren't a memeber. Here, this one might work: https://video-dft4-3.xx.fbcdn.net/v/t43.1792-2/22737478_120669238628430_1547282691601203200_n.mp4?efg=eyJybHIiOjE1MDAsInJsYSI6MTAyNCwidmVuY29kZV90YWciOiJzdmVfaGQifQ%3D%3D&rl=1500&vabr=653&oh=76bb0402c47a44f8741ef8c81079b39f&oe=59EC0114

Ah, wrong browser but it happens in 57 and 58. The link in the previous comment has expired, please delete?

(In reply to megarig_2000 from comment #41) > Yes, it still lags when scrolling. My point is, I tried to create a test build which can test this bug even with any pointing device. So, my question is, the builds in comment 40 can reproduce this bug even with usual mice, without specific pointing device of some notebooks. I feel the scroll slow, but I'm still not sure if that is *exactly* same symptom which is reported as this bug.

Yes. Tested on the same computer and X32 variant of Firefox. Of course, unbearable on touch pad. Using a physical mouse, slight lag going up or down but it is better. Doing a madman thrash going up and down fast does show full stops from it moving. Firefox 57, slightly laggy going up or down, delays in question. If going up and down like a madman, it is worse, a while for it to react. Using physical mouse, it is smooth going up, down, or madman-scrolling of up and down. Windows 10 X64 Home. A6-6310 (1.8Ghz Quad-Core (Single Core Turbo 2.4Ghz)) 4GB RAM and HDD.

Thank you. I'll land the change to Nightly for making anybody can test/emulate the odd behavior of some touchpad utils.

Because of the fix of bug 1410988, anybody can test/debug the symptom with setting "mousewheel.debug.make_window_under_cursor_foreground" to true.

(In reply to Masayuki Nakano [:masayuki] (JST, +0900)(offline: 10/24) from comment #49) > Because of the fix of bug 1410988, anybody can test/debug the symptom with > setting "mousewheel.debug.make_window_under_cursor_foreground" to true. It was worse with touch scrolling, than with off. Mouse can show stutter, non-smooth, scrolling. How will this fix it? I do use Nightly, so I will test on any updates.

(In reply to megarig_2000 from comment #50) > (In reply to Masayuki Nakano [:masayuki] (JST, +0900)(offline: 10/24) from > comment #49) > > Because of the fix of bug 1410988, anybody can test/debug the symptom with > > setting "mousewheel.debug.make_window_under_cursor_foreground" to true. > > It was worse with touch scrolling, than with off. Mouse can show stutter, > non-smooth, scrolling. > How will this fix it? I do use Nightly, so I will test on any updates. As showing the pref name, it's not for fixing this bug. It makes any developers debuggable what occurs when mouse wheel causes setting focus to popup window, even with any mice.

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #28) > I wonder, why the popup panel needs to reflow something when it becomes > active? I guess that it's autohide panel and it doesn't assume that > activated event won't come during visible. Maybe Neil knows the answer to this? With the pref flip from bug 1410988 it should be possible to reproduce this.

With the preference enabled from bug 1410988, it hits that code in WinMouseScrollHandler.cpp that was added. That code will try to activate the widget (call ::SetForegroundWindow) that is at the mouse cursor position which will be the panel widget. That isn't really allowed so Windows will then redirect it to the main window. But spurious activate messages will be sent to the panel and main widgets. I'm assuming that code should actually be checking for popups and not trying to activate them. The window will restyle during activation and deactivation to update things that have -moz-window-inactive.

I have tried this try build and it looks much much better. I would say that the bug is fixed by this.

(In reply to Eddward from comment #55) > I have tried this try build and it looks much much better. I would say that > the bug is fixed by this. Thank you for your test. In my environment (with the debug pref), CPU usage is 3 points improved (9% -> 6%). Most of the cost is each call of SetForegroundWindow() in MOZ_WM_REACTIVATE message handler since TSF needs to initialize something for reactivated window. Unfortunately, I have no idea to save this cost. If mouse driver activates popup, even if we want to cancel it, only visual change (e.g., color of non-client area like title-bar) can be prevented. In other words, we cannot prevent native focus change of Windows. Therefore, we need to call SetForegroundWindow() to make owner window of popup keep active. If we don't do this, we'll see odd behavior if you do: 1. Turn wheel on bookmark panel. 2. Turn wheel on another Firefox window. Then, the owner window of bookmark panel keeps (looks like) active and bookmark panel is not rolled up. Additionally, I worry about confusion of some 3rd party tools like a11y tools. So, somebody should contact the vendor to stop such illegal behavior.

Comment on attachment 8991206 [details] Bug 1399126 - Make nsWindow for Windows not notify widget listener of activated/inactivated if active window is changed from/to popup window https://reviewboard.mozilla.org/r/255988/#review263498

Pushed by masayuki@d-toybox.com: https://hg.mozilla.org/integration/autoland/rev/9c66627fee18 Make nsWindow for Windows not notify widget listener of activated/inactivated if active window is changed from/to popup window r=jimm

Should we let this ride the trains?

I think that this should ride the train because: - the patch stops running some code to prevent dispatching unexpected (in)activated event. - so, it may cause regressions if we unexpectedly stopped running necessary part too. - root cause of this bug is odd behavior of specific pointing device drivers. - the "odd" means that they do what they shouldn't do as a Windows application. - it is not so usual job to scroll on popups, perhaps, most cases is, scrolling dropdown list. - however, even in such case, this just consumes CPU resource, not causes any inconvenient behavior.