From the Cobalt 10.55341, there defined the SbDecodeTargetFormat2PlaneYUVNV12 format in SbDecodeTargetFormat in starboard/decode_target.h, but after searching through cobalt source code, there is no place to use the SbDecodeTargetFormat2PlaneYUVNV12, so does cobalt support SbDecodeTargetFormat2PlaneYUVNV12 at present? If not supported yet, when does it can be supported?
Unfortunately you are correct, Cobalt does not yet support rendering SbDecodeTargets with the SbDecodeTargetFormat2PlaneYUVNV12 format.
That said, we can add support for it. I've created https://issuetracker.google.com/issues/38428106 to track this issue, please follow that bug for updates on progress, and also let me know if there is a particularly urgent need to have this support available sooner rather than later, otherwise I'm planning to work on this within a month.
Related
i was poking in the Youtube-app for the Nintendo Switch and saw that it's the cobalt browser pointing to youtube.com/tv. Since the switch is lacking a (good) browser*, i thought that it may be possible to compile a/the browser for the Nintendo switch myself. Learning about the topic showed me that i don't know nearly enough to do this myself and i also have no idea where to get some help with this.
Switch apps are compiled with the nx_sdk, which is reserved for "approved" developers and under an NDA, so its not exactly easy to try to copy what Youtube did. We do have a toolchain to compile homebrew and it features a lot of the same things of the official SDK but it's still just for hombrews.
In my despair i tried to modify the Youtube-app to just use a different domain than youtube.com, which works but there are other checks in place that i cant really solve with my limited assembly knowledge.
So i my question(s) is/are: Is there a way to get cobalt to the switch as homebrew? If yes, where can i start and what do i need? Is the youtube-app (switch) source code available somewhere (minus the switch SDK)? What else could lead me to an acceptable solution of having a/the browser on the Nintendo Switch?
* Officially the switch has no browser, however there is a very limited Netscape browser for situations like wifi-captive portals or triggered by ingame TOS, health notices or video playback. The browser can be run by homebrew any time but like said above, it lacks functionality that other browsers all have.
The Cobalt source is available from https://cobalt.googlesource.com/, but it won't include the Switch port code. You could try implementing your own Switch port, but it is not going to be trivial.
More importantly, though, Cobalt is not a general-purpose browser. It is not based off of WebKit, and it only implements a greatly reduced subset of web specifications. Websites will not work out of the box on Cobalt, so it's not a promising endeavor.
Cobalt is designed to run single-page web apps that target Cobalt directly. By making many simplifying assumptions, it can be more embedded-friendly.
I use Firefox for about 90% of my overall browser usage experience and periodically discover bugs or strangeness in work, also from time to time I have suggestions for improvement.
So I think that it's useful for Firefox community to know about potential or actual problems. Is there such resource to create quick reports (I'm at work, for example, and haven't enough time for advanced conversations)? What is the easiest way to report bugs and suggest some new ideas? May be there is some addon for this purpose?
Thanks in advance.
Good question! Depending on the problem you are seeing, there are different strategies for efficiently reporting the issue. Efficiency in this case means the reduction of the time that passes from your report to actually get somebody to take a look at it (and then decide what's next).
Here's a set of ways you can use to get in touch with the community (disclaimer: I'm part of it):
Bugzilla: it's the one stop place for reporting bugs for Firefox. I know it's a bit cryptic at first, and there are plans to improve the bug reporting workflow. There's a comprehensive article on MDN that explains how to write a good bug report that's actually helpful. Don't get mislead by the word "bug": Bugzilla is also used to track the development workflow and discuss enhancements.
webcompat.com: if you're having problems with a particular website that doesn't get rendered properly, you could still write a bug report in Bugzilla. However, the webcompat website (still supported by Mozilla) is more suited for this kind of things. It also features a downloadable Firefox addon to speed up filing website compatibility issues.
Github: some components (Testpilot, ...) live on Github rather than in the central Mozilla repository. If you're experiencing issues with them, you could file an issue on the github page for the specific project.
irc.mozilla.org: (discontinued) this chat server allows to get in touch in real-time with the Mozilla community. There are several channels you can hang out in, even using a web-based IRC client. People are usually very willing to help. This is not the best place to report problems, but still a good place to raise awareness about your bug if it doesn't get triaged (i.e. assigned a priority and discussed) within a week or so.
chat.mozilla.org: as of May 2020, this replaced IRC and is the new recommended mechanism for synchronous communications. See the related wiki.
I know that's a lot of info, but it's easier than you think! If you feel like you don't know where to file bugs, just go to Bugzilla. Please do not hesitate to ask if you need more help and.. cheers for willing to report bugs!
Updated May 2020: Added Matrix and marked IRC as discontinued.
I have the source code from a plugin for second life to play in a browser but the problem is it's been created for Firefox 3.5, so what I'm trying to do is to bring it up to speed and upgrade it to the current Firefox.
Unfortunately I'm not sure how to go about this as I am literally just looking into this now, any help is greatly appreciated
What's your main aim here? Are you interested in simply making the extension work somehow in the latest firefox or are you more interested in optimizing performance?
Optimization of an application is a very general topic. You can look into the upgrades Gecko has gone through in the recent versions. If there seems to be any specific module for which Gecko is now offering a better interface/compatibility, you might try adapting the same. Again, this is really the programmer's judgment and skill which lets him draw the boundary between feasible and non-feasible development. For a module which is extensively linked with many other modules, it might be a good idea to leave it as it is to avoid sleepless nights (of course that's just my opinion. For some, that is the real kick :D).
If you are interested in creating high-performance plugins, you might like to give Google Web Toolkit a try. It is a Java library which compiles java into optimized javascript introducing various performance oriented quirks. I understand that it is not possible to switch an entire application to GWT easily and wouldn't help you just now, but I think it is worth mentioning for future use.
On the other hand, if you are just interested in making the extension work, you may look into Nightly Tester Tools, which is an extension used to override add on compatibility.
Lately, we have noticed that not all Firefox versions are playing the same game when it comes to layout and I wanted to find out if there is a definitive guideline when it comes to developing for Firefox.
What we're having to do is use Portable Versions of FF and then test across these versions but this is becoming a major headache! If someone knows of a script that will fix these issues across different versions of Firefox, I would appreciate it. Else, if there is some guidelines I can follow, I would appreciate that too!
Thanks,
James
The behavior you see might be an intentional change (e.g. to comply with the HTML5 spec) or a bug (a regression). If it is the former it should be listed on https://developer.mozilla.org/en/Firefox_4_for_developers or https://developer.mozilla.org/en/Firefox_5_for_developers. These pages are usually created in advance of a major release (e.g. https://developer.mozilla.org/en/Firefox_6_for_developers exists already) so that you can see if something affecting you is coming up. If a change breaks backwards compatibility there should be hints on how web developers can deal with it.
If it is a bug then it should be reported on https://bugzilla.mozilla.org/ along with a minimized testcase, marked with the "regression" keyword. Regressions that are reproducible and that affect web applications usually get looked at pretty quickly.
That's a very broad answer to a very broad question. For more useful answers you should really provide some details with your question.
I can't seem to find anything on google about this. I know you can pretty much rule out IE. I know webkit supports it but what else do you know?
Ok, this question has been here quite a while, but I wanted to add this anyway.
Regarding a question about browser support, a good source is always the caniuse.com website.
In this case, you can find the current, past and expected future support for the range input here:
http://caniuse.com/#feat=input-range
At the time of writing, apparently (Desktop) Safari, Chrome and Opera support range inputs, according to Dive Into HTML5.