The symptoms are that with an in-memory document, the debugger comes up blank, and the following warnings are reported by chrome's developer tools:
/deep/ combinator is deprecated. See https://www.chromestatus.com/features/6750456638341120 for more details.
debugger.html?ids=:10766 Calling Element.createShadowRoot() for an element which already hosts a shadow root is deprecated. See https://www.chromestatus.com/features/4668884095336448 for more details.
::shadow pseudo-element is deprecated. See https://www.chromestatus.com/features/6750456638341120 for more details.
...which is a shame, as there are some behaviors which differ between a server-backed document and an in-memory one, and so the debugger would actually be pretty helpful.
In addition, when you attempt to close the (blank) debugger, it stays open and the following alert pops up:
The page at https://www.gstatic.com says:
Unknown target origin, cannot post
Any workarounds to this?
Currently there is no workaround for this. The debugger has not been implemented to work with in-memory documents. I will update this question should it change in the future.
Related
When developing my react app the app becomes unusably slow with the devtools open in chrome. Works fast and fine with them closed or in incognito mode. I have tried disabling all extensions and had the same problem. This seems to have started happening recently when I updated chrome (now on Version 80.0.3987.132).
I am not really sure where to start debugging this issue but it has become very frustrating to develop on my app.
Any advice or help debugging would be appreciated.
TL;DR: Go to the Sources tab and delete all breakpoints for the site.
I had a similar problem. My site was very slow to load, but only in specific circumstances:
Dev-tools were open.
Tab was in a normal window. (not incognito mode)
Profiling was not enabled.
If (and only if) all three of those conditions were met, the site would load unbearably slowly (15+ seconds; normally ~3s), plus have performance issues for certain operations on the site (like changing which subpanel was open). It was very strange.
Like you, I tried disabling all of my extensions, yet the problem persisted.
Attempt 1: I tried clearing all of the site's cookies and local-storage, using the info/lock dropdown at the left of the address-bar. Suprisingly, that seems to have fixed it! (edit: this was not the root problem; see below for that)
So the problem must be that my site was storing too much data in local storage or something, such that dev-tools was choking on it (but only in specific cases, for some reason). This also matches with the issue resolving in incognito mode: incognito mode uses a "clear slate" for site cookies/local-storage.
Anyway, it's an odd one, but the cookies/local-storage clearing seems to have worked for my case. (If the issue comes up again, and the solution above doesn't fix it, I'll try to remember to mention it.)
Update: Oddly, having the profiler on still speeds things up even after the fix (ie. those three conditions being met still slows down page loading and actions, just much less than before the fix). So apparently the fix merely "reduces the intensity" of the problem rather than fully fixing it; like, by resetting local-storage, it lessens the size of that data, which somehow is a variable affecting the core problem (not yet identified).
Attempt 2: I believe I have found the root problem and solution: I removed all breakpoints for the site, and the slowdown was solved completely. So the problem seems to be that I had lots of unneeded breakpoints set at various places in my website code (some enabled, some disabled). Some of these must have been placed in/near "hotspots" that were getting called frequently. By having the dev-tools open, the Javascript engine must have had to start performing some processing related to the breakpoints, slowing things down.
My guess is that the problem would also be fixed by disabling the "JavaScript source maps" settings (as that's the only thing I can think would cause so much slowdown), but I haven't confirmed this.
This has most probably something to do with this commit, titled "Stop sending profile data when recording is off".
They already know there is an issue with the Developer Tools slowing down and they tried to prevent it by preventing profiling data to be sent via the bridge to the frontend, when not recording.
As reported, it seems the issue is not happening anymore, on the latest version. However, the cause is still unknown.
Try uninstalling the Developer Tools extension, clearing browser cache and then installing it again.
You should probably try using a version other than the one you're using, Version 80.0.3987.132. The app you are trying to develop might not be suitable to the version you are using. Delete the extension you are using, clear and remove every trace of browser cache and then re-download the extension, like what Daniele Molinari said. It might help. If it doesn't let me know. I'll try a different approach.
I'm trying to capture a website using PhantomJS, in particupar I'm using Pageres.
This website has got:
AngularJS
LocalStorage use
AJAX requests to an API
So, I'm testing locally and I'm not getting expected results, sometimes the screenshot will work with errors -rendering part of the contents, sometimes it won't render complete contents.
It really looks like Pagerer gets not enough time to take the screenshot once the site has fully loaded. I already added delay option but it will fail anyways, actually I could said it has worked better with out the delay option.
This is what it should be rendered:
And when it has worked best, this is what I get:
This is my code for rendering:
var pageres = new Pageres({})
.src('fantastica.a2015.mediotiempo.com', ['1440x900'], {delay: 3, crop: false});
pageres.on('warn', function (err,obj) {console.log(err,obj)});
pageres.run(function (err, screenshot) {
screenshot[0].pipe(response);
});
And, (I know there would be MUCH code to explain now) this is JS code being rendered.
Any particular advice?
Be aware of the differences between Phantom versions.
Phantom 1.9.x (which Pageres is using) is a browser engine from quite a few years ago (Chrome 13 is the closest equivalent) and will not render many HTML5 features.
Phantom 2.x is a much more modern webkit engine. But because of: a) because they have not produced a ready-made linux binary; b) some small API changes, projects like CasperJS and Pageres are holding back on supporting it. According a comment in https://github.com/sindresorhus/pageres/issues/77 if you make your own binary, and symlink to it, it works.
Also be aware that SlimerJS is an alternative to PhantomJS, based on Firefox rather than WebKit. There is no similar project based on Blink (to get screenshots how a modern Chrome would render them), but there is TrifleJS for IE. (However the Pageres pages say it is not the goal of the project to support other engines.)
Wait for DOM elements to appear, rather than using a delay.
Ajax calls, delayed loading, etc. make things very hard to predict. So, enter a polling loop, and don't take your screenshot until the DOM element you want in your screenshot is now visible. CasperJS has waitForSelector() for this case. PhantomJS has the slightly lower-level waitFor().
I think pageres would need a bit of hacking to add this functionality.
I'm experiencing trouble with an angular-ui plugin (ui-select): for some reason, I cannot select any option.
Looking in dev tools and changing the ng-click attribute for the relevant DOM element to alert('test'); doesn't result in the alert being called either. This leads me to believe ng-click isn't being called for some reason.
Anyway, since I cannot find any information on this and I'm suspecting there might be a compatibility issue with another plugin or library. I'm wondering if there is any way that I can debug ng-click operations. I'd like to be able to pinpoint where in the event chain things go wrong.
There is a very useful post related to this post regarding why angular fails silently on errors in expressions
The work flow I have found to work for me is to first double check that your controller method or function that you are calling exists in your current scope. This can be a pain to debug, but often times I have found it's just a typo on my part.
I would start by putting debugger in the first line of that function or method and determining if your program haults there.
PS:
another explanation for this behavior
Load Chrome to your web site.
Press F12 for dev mode.
Go to Sources.
Set breakpoints in your JS files.
Building a plugin via trigger.io, I'm seeing strange behavior in Chrome/Safari vs Firefox.
In Firefox, arrays are being turned into objects with numbers as keys, for example:
["getData", ["x"]]
Is getting turned into:
{"0":"getData","1":{"0":"x"}}
This causes all kinds of problems with serialization/deserialization, normalization across browsers, etc., and I'm not clear on why it would be happening.
This seems to be happening when passing objects from the foreground to the background via forge.message - happy to answer any questions to narrow this down!
That does look strange, could you let us know what version of Firefox you are using?
In the mean time you could serialize and deserialize the array yourself using JSON.stringify and JSON.parse.
This is caused by an error in Firefox's serialization of array in extensions, see: Firefox extension is sending javascript Array as an Object instead
As #connorhd said, the solution (until firefox fixes the issue) is to de/serialize to json when sending messages between the foreground and background. Unfortunately for us, this is a hotpath, and not terribly welcome overhead, but it seems to (more or less) solve the problem in Firefox 18.
Once the bug is set RESOLVED, the bug is completely removed from my bugs. I wanted to keep a track of the number of issues resolved. How could I see it and get back all in one list?
Go to any "Search" page and make sure "Status" is set to "all" (or whatever). The default is usually "open" and that's why you're not seeing your closed bugs. If you open the "Advanced" tab of the search, you can drill down very precisely.
Your search criterion "Resolution" may have value "---" which is a value, not a wildcard. Complicating things, usually web browsers don't give you an obvious way to deselect the only selected value in a multiselect list such as this one.
Fix:
You can deselect the "---" value of the "Resolution" search field by holding down the Ctrl key and clicking on the "---" value.
That works in Internet Explorer, Firefox, and Chrome. If I recall correctly it works in Safari as well, or maybe that uses Command or Option modifier keys instead of Ctrl.
Of course this fix doesn't apply to mobile devices. Long press? I don't know.
Alternatively there's nothing wrong doing like in Excrubulent's answer: work around this difficulty by selecting all of the values in the Resolution list.
Actually my BzDeck app [1] had the same issue. It was showing My Bugs in the main Inbox thread pane, the core feature of the app, but bugs would suddenly disappear when it's been RESOLVED. My solution was adding a selector to display all/open/closed bugs [2].
There are two different scenarios:
People usually would like to focus on open bugs (bug if they are involved in too many bugs, the My Bugs list could be very long), however,
People sometimes continue discussing on closed bugs (on BMO, RESOLVED FIXED for Firefox bugs only means the patch has been committed to the source code repository)
Given that, a better, possible solution would be:
Distinguish clearly open bugs from closed bugs like GitHub issues (this applies to the all UI on Bugzilla; GitHub issues use green and red icons for this purpose [3])
Provide a selector like BzDeck to switch between all/open/closed bugs, showing all bugs by default
Load/show the bug list lazily to improve performance
As mentioned, My Bugs was the core of BzDeck as well as another experimental Bugzilla client called Buggy [4], and I believe Bugzilla should also implement the same thread sidebar so people can go though their bugs much faster.
https://bugzilla.mozilla.org/show_bug.cgi?id=1380026
Searching under the advanced tab for resolved bugs doesn't work in some versions of Bugzilla. See this bug on the Bugzilla Bugzillaception:
https://bugzilla.mozilla.org/show_bug.cgi?id=663377
That bug says resolved for 4.2.1, but I'm using 4.2.5 and it isn't fixed for me, so apparently your mileage may vary. I've mentioned this issue on that bug.
A potential workaround for now is to search for various resolution values (FIXED, WONTFIX, WORKSFORME, etc). Anything with those values set should have a status of resolved or verified.
When you are using the quick search, ALL is your friend, this word has to be typed at the very beginning of the input line and overrides the status criterion (as can be found in: Examples of Simple Queries).
BTW: Bugzilla's quick search can also be added to the Browser's search engines and combined with a keyword also within its address bar. (confirmed for Firefox and Edge)
I warmly recommend the 5½-minute summary in Bugzilla Quicksearch will BLOW YOUR MIND on YouTube.