I'd like to configure bugzilla to reopen parent bugs if a blocker is reopened.
This, to me, seems to mirror the option I see of preventing a parent from being resolved if a child is not yet resolved, but I don't see an option to accomplish it.
There is no such option. OP's request to add it was resolved as won't-fix with this comment:
Hmmm, I suspect that that would be better as an extension, because only a few organizations are going to want it.
No mention in the bug of anyone stepping up to contribute such an extension, though.
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 make a merge operation with Subversive in Eclipse.
I've been able to manage all the conflicts on the files structure, but it remains a conflict on the svn:mergeinfo property.
I've tried everything, but I'm not able to solve this conflict:
The plugin has a Mark as merged option, but it doesn't happen anything choosing that option.
I have also tried to remove the property, or to modify its own value, but nothing happens in any case, and the conflict is still present.
If I try an Override and commit, the status of the Folder of the project is Conflicting, also visible in the SVN Info on the properties of the project.
It seems that Subversive can't manage a conflict on this property: is that possible?
How can I solve this conflict?
Thanks in advance!
Even though I haven't found yet a solution directly with Subversive, I hacked the issue using a tool like SmartSVN.
With that tool I had been able to mark the conflict as solved, so I can say that it's a bug (or maybe a missing feature) of the current version of Subversive.
I'm having almost the identical problem as here. Unfortunately this question provides no solutions. I'm using strictly HTTPS and still have the problem. I've tried all I can think of: Session.checkAgent=false, Session.cookieTimeout=0, Security.level=low, etc. I cannot re-produce the problem in any way, however, a small portion of our customers are complaining that their session is being lost. I don't know any way to debug and/or determine how/where the session is being destroyed. I don't know what else to do, can anyone help? I'm using CakePHP 2.4.5 and can upgrade to 2.5.5, but would like to determine what the issue is so I can have peace of mind that it has been fixed.
This may help
Configure::write('Session.referer_check' ,false);
But before putting that into production, you should know how it may affect your security.
The only real way to fix this is if you can reproduce it.
While exporting a Solution from CRM, I dont get the prompt to save the exported solution.
I cleared Cookies and tried,
Upgraded to IE 9 also and tried,
I made sure that the Popup is not blocked, but these things didn't help.
This is the case with few other colleagues of mine also.\
Thanks
I usually get a popup right at the bottom of the window. Its not instant however, Crm has to generate the solution file, so if its particulary large it can take a minute or two. I would suggest clicking export, finish the dialog and then waiting 5 minutes to see if anything happens (it needs a loading icon really).
If that doesnt work, try the same again with a small solution (one entity).
I know it is too late but I am adding the solution here if someone faces the issue again.
The issue was due to URLScan. It was solved by removing URLScan from ISAPI filters for CRM web site.
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.