I have a chrome extension with an existing extension Id and a local update file (on our server) that is used by many users.
I uploaded the extension to the extension store successfully.
Seeing I needed to make some changes I deleted the extension from the store.
I made the required changes and tried to upload the amended extension file again (with the same id). I got the error: ""An error occurred: Gallery system error, please try again later."
I read in some forums that I should wait. I'ved tried a few times and it almost 2 weeks since my first uplaod and I still cannot upload my new extension.
How can I resolve this?
Is there something that can be done to resolve this issue?
Chrome Web Store does not allow duplicate upload even after deletion, we reserve the ID forever, however we do not have clear message indicating this so people delete item casually, we have improved the message. This has become a common problem as Chrome M21 forbids apps installation from outside of CWS, we should communicate this better.
If you have strong reason to need the item id back (such as you have already been distributing the item under the ID for a long time), please post your item ID and CWS account email at http://code.google.com/p/chromium/issues/detail?id=138706 and we can try do a manual recover for you as an exception.
Sorry for this inconvenience.
Related
We have recently updated to the latest forge-api-java-client jar.
There are currently issues when calling /modelderivative/v2/designdata/{urn}/metadata during a PDF upload.
As the request object cannot be mapped into the Manifest response due to errors with unknown enums being returned for ManifestChildren.RoleEnum
Manifest -> ManifestDerivative -> ManifestChildren -> RoleEnum
I have been able to work around this issue by adding the four missing enums (leaflet, leaflet-zip, pdf-strings, pdf-page) to the jar and building it locally.
I have searched and cannot find any release notes around these new enums/response objects, and was wondering if I could get pointed in the right location for these changes so I can keep an eye on future updates.
Also I would like to confirm that there are not other changes in the recent updates that may affect other Manifest responses we have not yet seen.
Thank you for any help.
Thank you for bringing that up. The leaflet/pdf roles have been around for a while but I don't see them documented anywhere, either. I'll talk to the Model Derivative team and make sure that the roles are documented.
As for the Java SDK, please submit a Github issue or a pull request to https://github.com/Autodesk-Forge/forge-api-java-client and we'll take a look at it.
I found the following issue here in stackoverflow however cannot comment as yet. I have a similar issue and wonder if there is anyone out there that has solved it.
https://stackoverflow.com/questions/40917501/tfs-2015-web-portal-code-viewer-not-working#
I am encountering similar here. In house TFS 2015, can't view code in the web portal using Google Chrome however IE is fine. I, however, am not using HTTPS so may be experiencing something slightly different.
When I do try to view a file in Chrome, the window where the code listing should be is simply blank. I did note too that the button for creating a new build definition appears to be indicating a broken image link.
This has not always been an issue. Around 4 months ago I could get the code view fine in Chrome and, to my knowledge as I have no access to the servers, nothing has changed apart from Chrome updates.
I've tried getting to previous versions of Chrome to no avail, though I wouldn't know which version I was on when this did work.
Interestingly, I have one or two .MD files around and these display perfectly well. They are simple text files. However when saved with .TXT extension (or anything else I've tried), they do not show. Curious.
Update
As you will see from the screenshot below, when selection on a file has been made, in this case a .SQL file, where I would expect the view to populate nothing at all appears.
As for the F12, I do get 5 of these:
Failed to load resource: net::ERR_CONNECTION_REFUSED
plus associated paths of course. We use Webroot internally here which has recently dropped in a Chrome extension however even when Webroot is disabled in its entirety (including removal of extension) I get the same behaviour.
All other Chrome extensions have been removed too at varying times to try to give a clean browser.
I have no other pop up blockers, ad blockers, etc installed on the workstation.
Problem solved thanks to the F12 key suggestion.
After some grovelling I was granted domain admin privs to have a dig around everything. It turns out that TFS was installed on ServerA with a URL port of 8080, this I knew from the original install and obviously the path I follow to get to my TFS web interface. What had also been done subsequently, with no consultation of the Dev user group, was that a second TFS application tier had been installed on ServerB, the port here was 8088.
I had not noticed the difference in path initially, assuming it was Chrome or workstation related. Anyway, I altered the port on ServerB to 8080 and everything jumped into life. I should not have made assumptions and should have paid more attention to the path in the error!
It seems the second application tier was set up on a non-production environment to allow senior Dev users access to the TFS Management Console rather than allowing them access to the original app tier which was on a production box. Our IT Operations just forgot to tell anyone.
Try to update your chrome to latest version of (55.0.2883.87 m (64-bit)).
Also clear the cache of chrome. I have also encountered similar issues. The solution is clear cache and connect to the web portal use another ID, then connect back use the original ID. I have no idea which one solved the problem. You could try both.
This problem should only be an individual phenomenon, since TFS2015 has been released for a long time.
A little background info...
By far and large the URLs worked perfectly fine. Occasionally either my machine, or the server itself couldn't access the Web Service URL or the Report Manager URL. For the server a restart fixed this, for me I had to reset my winsock which never worked and ended up System Restoring to a working date.
When I say couldn't access I mean getting the "This Page Cannot Be Displayed" message, or the "Please turn on TLS 1.0 etc etc" message.
The last few days the issue is now widespread. Everyone was having issues gettings to the URLs even the server. I figured it may have been some windows updates causing issues so I removed all the updates around the timeframe in which it started and tested and got nothing.
Came back the next day (today) and same issue except the only way to access it is through a hyperlink thats clicked or copy/pasted.
The issue:
If you manually type the URL it will not work. You have to copy and paste the hyperlink from a working page. I used a link to a rendered report and deleted back to /ReportServer and it pulls up the directory. I've never seen something like this happen before.
The Solution:
Apparently you have to type in www. as well
I was so use to skipping that for most pages.
https://analytics.domain.com/ReportServer = fail
https://www.analytics.domain.com/ReportServer = win
I have the following Problem:
I recently started using TortoiseSVN in order to Commit and Checkout .MDA Files, and while testing everything out I noticed that .MDA Files that have been Checked out of TortoiseSVN have a problem with Forms. They simply dont Open in Access when double clicked, no Error Message, no Window, simply nothing happens. In order to Fix this, I currently simply rename a control in the Form and Name it back to the Original Name. This usually fixes the Problem but is a time consuming process in .MDA Files with many Forms.
Is there a known Fix for this Problem or does someone have an Idea why this Problem occurs?
I know this was asked before but this is what I'm experiencing -
I'm working on a Chrome extension that needs to persist some data and I'm using localStorage for that . When I go to Settings->Tools->Clear Browsing Data and check everything (including 'since the beginning of time') , I would expect the localStorage of my background page to clear .
However everything stays put. The localstorage wasn't deleted!
It's not that I don't like that behavior , it's actually pretty great for my app , but is this normal ? Shouldn't localStorage delete once the user tries to clear everything , just like cookies should delete?
P.S
I found this nice blog that asks and tries to answer the same question :
http://sharonminsuk.com/blog/2011/03/21/clearing-cache-has-no-effect-on-html5-localstorage-or-sessionstorage/
Seems like the behavior changes from browser to browser . The behavior I talked about happens on Chrome 28.0.1500.71 m
This bug is not normal behavior. ( to answer your question )
I'm calling this a bug because someone might be using a computer at a library with some type of locally hosted application. There is a clear expectation that data is not retained in any way under a purge called "beginning of time"
Firefox purges localStorage data when you clear all browser data. It does this if the file is stored locally or hosted on a web domain.
Chrome purges localStorage data only if you code is hosted on a domain.
I made a video of this bug..
https://youtu.be/CgojKg4v7X0
Save this URL with HTML/JS a local drive to reproduce the bug...
https://html5dataprivacy.github.io/
steps:
- load a local web page containing javascript HTML5 storage code
interact with the page that stores your data in a way that changes the data
clear everything in history until the beginning of time
give the keyboard and mouse to another user in the library or public cafe...
result: That javascript storage is retained , another person can see your data...
expected result: The data is purged for the new person at the keyboard
notes: This bug does not exist on Firefox current version as of April 19th, 2017. Does not fail if chrome is working off a hosted domain
Workaround: After you clear things to the beginning of time you must open up the console and type "localStorage.clear()"
ps: please be kind. This is my first attempt to answer on StackOverFlow :)