Network category filter tags have wrong UI state when devtools run with HTTP mode
Reported by
muzui...@gmail.com,
May 2 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0 Steps to reproduce the problem: 1. run Chrome with "google-chrome-unstable --remote-debugging-port=9222" 2. Open any devtools instance, like "http://localhost:9222/devtools/inspector.html?ws=localhost:9222/devtools/page/33fa1a8d-b94a-4e14-957d-08cf748a26f2" 3. Switch to "Network" panel. What is the expected behavior? What went wrong? All the catgories tags are in checked state, click any tag, all tags state will mess up. They don't work like when devtools run with dockable mode. Did this work before? N/A Chrome version: 60.0.3080.5 (Official Build) dev (64-bit) Channel: canary OS Version: Fedora 25 Flash Version: 24.0.0.189 internal-not-yet-present It look like when devtools run with HTTP mode, there are no default "category filter" setting, so all the tags initial state are in checked state. I found out how to fix it, change the code in https://chromium.googlesource.com/chromium/src/+/60.0.3087.2/third_party/WebKit/Source/devtools/front_end/ui/FilterBar.js#396 to this._typeFilterElements[typeName].classList.toggle('selected', this._allowedTypes[typeName] || false); pass "false" to force "classList.toggle()" remove the class name, will not affect by the initial state.
,
May 3 2017
Able to reproduce the issue on Windows 10, Ubuntu 14.04 and Mac 10.12.4 with chrome #58.0.3029.96 Issue broken in M-49 Bisect Info: =========== Good build : 49.0.2579.0, Revision Range- 362585 Bad build : 49.0.2580.0, Revision Range- 362859 After executing the old bisect script, i got the following CL's between good and bad build versions ============================================ https://chromium.googlesource.com/chromium/src/+log/d7f8dad941a8d06f1f53d0e285c1f2d9af28a8fe..ed51b0466a5052d25e831ad970215fa634b8c47a The suspecting Change Log is : ----------- https://chromium.googlesource.com/chromium/src/+/a9a901bc9a158c5e60cda9bbb96fa50ce0c76489 Review-Url: https://codereview.chromium.org/1476863003 yukishiino@- Could you please look into this issue, if it's related to your change? if not could you please help us to reassign this issue to the right owner. Attaching the screen-cast for reference. Thank You...
,
May 9 2017
Thanks for bisecting. However, the CLs under suspicion is 1 year 5 months old. Assuming that this issue started happening recently, they shouldn't be directly related. pfeldman@, could you triage this issue?
,
May 9 2017
,
May 18 2017
As the Cls commit says
> With this change, overloaded C++ functions, such as foo(int, int, T*)
and foo(int, int), will be resolved correctly. Note that
DOMTokenList::toggle("name")
and
DOMTokenList::toggle("name", false)
behave *differently*. (Oh, my...)
So, it's important to count the actual number of arguments correctly.
So `classList.toggle()` work like web standard define https://developer.mozilla.org/en-US/docs/Web/API/Element/classList#Methods
We should pass second argument with `false` to remove the class name.
,
Dec 1 2017
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by eostroukhov@chromium.org
, May 2 2017