I have a PWA that saves data locally to indexedDb. Works fine. But I feel hampered by a lack of an editor like SSMS for SqlServer. To make a small change, I have to edit code.
I wondered if anyone had seen any tools (it looks like a chrome extension could do it) that might be useful? I'm working with Blazor (have a lot of Vue.js and Vanilla JS experience, but Blazor is just more productive).....so a component I could add to my application would be a major bonus!!
Prefer to avoid homebrew if someone has something already.
What do you mean by
so a component I could add to my application would be a major bonus
To inspect and make changes directly in the browser have a look at the Chrome DevTools.
I want to use Puppeteer to automate a particular task. However, for user-friendly purposes, I thought about implementing it within a chrome extension. Browsing the web, I encountered this article https://dev.to/tchan/web-automation-using-puppeteer-inside-a-chrome-extension-318o To be honest, I could not absorb some context from the article since I don't have enough experience about that kind of stuff. According to the article, I had to activate remote debugging for chrome. So I did, yet could not access localhost, thus webSocketDebuggerUrl property, either. Some connection refusal error hit on the browser while trying to access. But the thing about I care is that in the case that it even works, if I had published this extension, one would have to activate his/her remote debugging for chrome, too and that would not be much of user-friendly. In the end, I thought that if it is possible to run Puppeteer on nodejs with your own computer, it should be possible to run it on server-side(nodejs) of a website, too. Thus, you wouldn't need an extension, so the website itself would implement the task I have intended. Sorry for this long story-wise problem, but still I don't have much knowledge of server-side languages. So is it possible to run Puppeteer on server-side? So what would you recommend to do?
Thanks.
I'm developing a Chrome extensions that would be installed simultaneously with a desktop app, as an "external extension" as the docs call it. But I believe the extension would be disabled, and users would need to manually enable it. It's inconvenient to do this and not at all obvious how (at least to users not very familiar with extensions).
Is there a way to automatically enable the extension, or make it very easy for users to manually enable it? This was asked in the comments on this other stackoverflow question, but no one had an answer.
Another issue is that I think Chrome has to be restarted for the extension to be installed at all. This is obviously very disruptive from a user perspective. Is there a way around this?
I have been developing Chrome extensions and as I have already mentioned in a question on SO, I have problems paying that starting charge witch Google asks. So I quit wasting my time developing extensions for a company that has no respect for developers and I'm starting to develop Firefox add-ons. So I'm a total newbie in this area.
First of all I have to mention that I am NOT looking for an automatic functionality/way to convert them. I have noticed that one difference between Firefox add-ons and Chrome extensions is that there is not such a thing as popup.html in Firefox (maybe I'm wrong).
How can I find other main differences so that I can convert my extensions to Firefox add-on?
Firefox addons do have a popup paneil in their SDK available to use(https://addons.mozilla.org/en-US/developers/docs/sdk/latest/modules/sdk/panel.html).
I'm developing a Firefox addon right now and I can tell you that their actual SDK and the develop environments are great, cfx to work offline or the online builder, both are powerful and easy.
Regarding the differences that you ask, besides a few structure differences and of course Chrome or Firefox specific code that is not going to work in the other platform, I think that it should be easy port an addon from one platform to another, no automatic but pretty straightforward.
I'm tyring to get phonegap up and running on blackberry storm (9530 simulator). I had been testing my webapp from withing BB's built in browser, and it was looking ok, but then it totally bit once I tried to look at the some code from within phonegap, even though I was pointing phonegap to the same url (I hadn't yet gotten to the point of running code locally on the device).
I tried a test case on google and got similiar results. see below. I suspect that I'm missing something basic here. I would have expect both images to be nearly identical.
Browser
http://www.eleganttechnologies.com/outside/ImgDeviceBB9530WebGoogle.jpg
Phonegap
http://www.eleganttechnologies.com/outside/ImgDeviceBB9530PgGoogle.jpg
[Update]
To shed some light on what is happening, I ran the browser and the embedded browser (phonegap) against the W3 mobile web acid test: http://www.w3.org/2008/06/mobile-test/
I definitely notice differences between the two, but I don't yet know the 'why' and the 'how-to-address'.
Acid via built-in browser
(source: eleganttechnologies.com)
BTW - I ran this earlier today and got a couple more green square than just now.
Acid via browser embedded into phonegap
http://www.eleganttechnologies.com/outside/ImgDeviceBb9530PgAcid.jpg
Disclaimer: I don't know anything about phonegap, but have a pretty good theory. By default the embedded browser control on BlackBerry uses an older version of the rendering engine than the BlackBerry browser itself does.
At the BlackBerry developer conference last year, a talk was given about this, and there's an undocumented option to use the newer rendering engine. \
The option ID is 17000 (yes, a magic number, which could change, use at your own risk etc), and should be set to true. Not sure how you'd pass this option through phonegap (I'm not familiar with the toolkit) but using the BlackBerry APIs it's something like:
BrowserContent content;
...
content.getRenderingOptions().setProperty(RenderingOptions.CORE_OPTIONS_GUID, 17000, true);
I don't know the specifics of the browsers you are using, but I do know that most of the big sites will detect your OS + browser combination to decide what HTML to show you.
If Google is seeing a different user agent, you might get a generic mobile version of the HTML instead os the Blackberry specific HTML you get for the built in browser.
If you have access to a web server, try hitting it with both browser setups and see if there is any difference in the log file. That might tell you something interesting.
As we can see in your Acid tests...
One browser (the built-in one) is reporting correctly as a BlackBerry9530, and the other (phonegap) is not presenting the user-agent ["Testing with ."].
In this case, Google is providing you with the default view of their homepage, whereas when you are reporting yourself as a BlackBerry device, you will get the BlackBerry specific rendering.
By the sounds of things, using phonegap is removing the default user-agent (most probably because it's not recognising your device). As phonegap is open-source, the best bet is to get in there, and debug it and find out what happens with the user-agent when the http requests leave the device and track it back from there.
Maybe one browser has capabilities that another one does not?
Hm. By looking at the screenshot I would say that the second page is probably missing some resources. It may be missing some images, scripts and the CSS files, which would explain different l&f. Knowing how Blackberry Browser Field API works, I would guess that the implementation that uses the BrowserField was not done correctly. Just my guess. In addition to that, when the browser field is initialized the caller needs to configure it properly by enabling the appropriate browser features - scripts, styles etc. Again, the API is done in a very weird way, I have gotten myself into this trap once. When setting the options, you cannot just create one mask (like CSS | WML | SCRIPT) and make one call. Options are numeric and, I believe, non-overlapping - but you still need to call the API for setting each option independently.
Also the way asynchronous loading of the resources for BrowserField takes time to understand.
Just my $0.02.