So I've been watching a course on a site(gov site)... and I already know everything about the stuff mentioned in it, I want to skip the video timings and jump to any part, as I have to submit the certificate to my teacher tomorrow, but its giving me restrictionsPutting an image for the same
I tried inspecting it, but couldnt find anything related to that block/restriction
Related
This is the first time I am trying to contribute to Mozilla. I went through several articles and documentation/resources to get a hang of what could be the best first steps to get started. I started off from this page http://whatcanidoformozilla.org1 and chose to start off with Java.
On initial tinkering I was taken to https://wiki.mozilla.org/Mobile/Get_Involved and eventually https://wiki.mozilla.org/Mobile/Fennec/Android/Suggested_workflow resource suggested that the best way to get started with it would be to pick up some simple bug and propose a patch for it.
So then I went to http://www.joshmatthews.net/bugsahoy/?java=1&simple=1 and this specific bug drew my attention. The description of the bug mentioned this :
There are some methods that we share (or can share) across our DB
implementations, like appending PARAM_SHOW_DELETED, PARAM_LIMIT, or
PARAM_PROFILE.
These are currently spread across LocalBrowserDB, TabsAccessor,
URLMetadata, and so on. It'd be nice to clean these up.
Question 1. Now how do I get some more context on what exactly is the bug and what is required to be done ?
As of now there seems to be 2 patches already submitted from what I understood (and please correct if my understanding is wrong here). So to get some context about the bug I went ahead and opened up the first patch submitted here.
It gave me some idea as to at least where exactly is the code itself that needs to be fixed. And I found it here
Question 2. Am I on the right track on how to figure out the code that needs to be fixed ?
Question 3. Even after reaching the DBUtils.java file I could not find any documentation about what the class basically does, or where does it fit into the whole picture. Could someone please help me with this, as to how do I figure out what a class is supposed to be doing etc. or at least some documentation around it?
You're on the right path. Basically, the What Can I Do For Mozilla website is a quick and easy way to let you discover projects you might be interested in, so it's the first gateway to the coding contributions.
That said, you did good in picking a bug to start off. However, as you saw the bug was already being worked on by somebody else (marked as Assigned). Your best bet is to find some new "good first bug" to work on. This might be a complicated task, as Bug's Ahoy shows only a few not owned good first bugs.
You should try to get in touch with the Fennec team, either via email or IRC (the latter for quicker responses).
Now, to answer your questions, in a more general way
Question 1. Now how do I get some more context on what exactly is the
bug and what is required to be done ?
Usually, this should be described in the first comment in the bug, on Bugzilla. If that's not the case, feel free to drop a message there and ask for more directions. You can also flag the reporter or the mentor of the bug using the needinfo functionality, as they are usually better shown.
As you can see, somebody asked for more info in comment 1 and some new directions were given.
In general, you won't find a patch with code on the bug itself, but you might find links to files and more precise directions on what to change and how. If not, again, feel free to ping the reporter and/or mentor.
Question 2. Am I on the right track on how to figure out the code that
needs to be fixed ?
You're on the right path. In general, if there are no links to files or DXR on the bug, but some code is mentioned, you can look it up using DXR, as you did.
Question 3. Even after reaching the DBUtils.java file I could not find
any documentation about what the class basically does, or where does
it fit into the whole picture. Could someone please help me with this,
as to how do I figure out what a class is supposed to be doing etc. or
at least some documentation around it?
What I usually do when navigating the Firefox code and need some more background on a not so well documented class, is browse the change log for that file, clicking on the Log button in the top-right panel on DXR (when displaying the file). It will show you a list of bugs that affected the file. You can even trace back the original file that implemented it, to get more context.
On the other hand, if you're only interested to the history of a single line of code within a file, then the blame tool is your friend. It tells you who last touched the line, the changeset and the related bug number. That is also accessible from where you can find the Log, here.
In the case of DBUtils.java, however, it looks like the class just holds some utility functions for database access.
To see how something is being used within the Firefox codebase, you can still use DXR. Here's a sample search for the DBUtils object.
Hello StackOverflow community,
I've just started having an issue with hyperlinks stored within an MS-Access table not behaving as expected.
I have a small database which, among other things, records links to documents hosted on a company Sharepoint site. Until a few days ago, all was working fine with both the database and the hyperlinks.
For some reason, within the last few days, whenever I (or any of my users) click on these hyperlinks through an Access form (or me clicking directly from the tables), I am getting strange behavior:
Clicking the link does open a new instance of the default browser, as desired. And that browser does navigate to the company Sharepoint site. But none of the links actually open the specific document that they are intended to point to.
Instead, all links are bringing up a general file/folder menu within the Sharepoint site. It is almost as if these links point to a non-existent file within an existing folder.
The very strange part is, if I "edit" any of the hyperlinks in my database, and simply select and copy the "address" text from within the edit hyperlink window, I will always immediately pull up the correct desired document if just paste the address directly into a new browser window.
I would have thought that this type of cutting/pasting would necessarily be equivalent to simply clicking the link. But that is obviously not the case.
I feel like I can safely rule out the possibility that any changes to the Sharepoint site itself would be causing my issue with simply clicking the links (otherwise cutting/pasting the addresses would not bring up the correct documents), but I have to admit I am simply stumped as to why just clicking the hyperlinks directly used to work, but no longer does.
I don't believe there is any code or other relevant information that might be helpful that I am neglecting to include, but would be eager to provide any clarifications/etc if anyone has any idea as to what might be happening here.
Thanks in advance for any thoughts or suggestions!
~JQN
EDIT: I had deleted this question because the issue described above had simply stopped happening. I was unable to explain why, but was also unable to reproduce the issue again after a certain point within a day or two of making the original post.
Since then, the issue has returned. I've been able determine the following:
As described in my note below, when I am getting this odd link behavior, I do NOT get the standard warning from MS-Access indicating that hyperlinks may be harmful, etc.
Strangely, simply opening up a file dialog/file picker and then navigating through that dialog to any location on the (sync'ed) Sharepoint site seems to make the problem go away. I do not need to actually select or open any location on Sharepoint, simply navigating within the sync'ed folder structure seems to do the trick.
Once this happens, all links behave as intended again (ie. they open the correct linked file directly instead of landing on the root folder page). They MS-Access hyperlink warning returns as well. The file/link behavior will remain in that state for several days. Only after, I'd estimate, a week or more of inactivity since the file dialog was last run will the issue return.
FURTHER EDIT: New update...Enough time has passed so that the issue is recurring again. As suspected, links to pages outside of Sharepoint are not affected, and open as expected without issue. Once again, the standard Microsoft hyperlink warning dialog is not coming up for any links.
Obviously, now that I've found the work-around with the file dialog, it's easy enough for me to fix the issue when it arises. I'm hoping that this rings a bell with somebody, though, and perhaps one of you could point me in the right direction for a more complete fix for my users.
Thanks again for any help with this!
YET ANOTHER EDIT: Ok....based upon all the things I've learned in the last couple of weeks (as captured in this post and the comments below), I was about to delete this question and re-post it as "Why is Sharepoint redirecting my URL requests from MS-Access?" As I tried to search the forum to make sure that that question hasnt already been asked, I stumbled across some info that I think gets at the underlying issue:
It looks like this is related to the (very opaque) way that Office processes URL requests. It apparently doesn't simply open the document at the specified link, it first "pre-tests" (I suppose that's the right word) the URL by sending a "Microsoft Office Protocol Discovery" request first.
Apparently, it is possible for Sharepoint to somehow not like the particulars of that MOPD request, and if that happens, then Sharepoint redirects to the file directory page -- and that directory page ends up being opened in the browser instead of the intended link/document.
Again, this only happens sometimes and not others. When it does happen, I've found a clumsy workaround that will correct the issue for about a week or so. I can't reproduce the issue during that week, I just have to wait for the workaround to expire (I obviously don't fully understand why my clumsy workaround works).
It doesn't seem possible to manipulate the particulars of the MOPD request. If possible, I'd love to be able to dispense with MOPD entirely, since I want all the files I'm linking to via Access to be opened as read-only anyway. Unfortunately, I don't think that that is possible either.
I've found some info on this in another SO thread HERE. I still am not quite at the point where I feel I'm ready to submit an answer to this question, but I have some ideas as to what sorts of things may function as an acceptable workaround.
It would be helpful if anyone had any ideas as to how I might be able to reproduce the issue on demand, rather than simply waiting another week for whatever keys/cookies/settings/etc to expire again. I'd need to implement any possible solutions entirely on the Access side of things if possible, rather than on the Sharepoint/server side. Thanks again for any suggestions!
I'm posting this as an answer now, but will avoid accepting it until I've had a chance to verify that it actually works.
I am inserting some code that will run on DB startup. It will open a (an invisible) form that has an Access WebBrowser control included. I'll have that control navigate to a specific file on the Sharepoint site. I believe that it is actually this action that somehow causes the link problems to resolve for a week of so.
This form will run silently in the background, navigate to the sharepoint file location, and then close. This should hopefully refresh whatever characteristics of the MODP request that are present when the links work properly (and are absent while they aren't working properly).
In essence, I'm hoping this approach will have the effect of resetting my (approximately) one week window of desired link functionality to start anew each time the database is opened. In other words, I'm thinking that this will work, although I still don't fully understand why.
Wish me luck!
;)
A friend has asked me to check out an old uni project he did using Construct 2. It was made using a uni copy of Construct so I have no way of editing the original files, and only have access to the online export. Please bare in mind that I've never used Construct before, so I have no idea how it formats it's code. I'm more of a web designer but I said I'd have a go.
So the issue is it freezes after a few seconds. If I click quickly I can get past the intro screen, but if don't click the game freezes anyway. In other words the error is not caused by user input but by something happening in the background.
The example is here - http://rosietheband.com/moeba/
Has anyone seen this issue before? I was wondering if using an older browser might do the trick, as it worked a couple of years ago when it was made, and nothing else has changed since.
It's a javascript error; I went poking around in Chrome's dev tools console and found this. The problem seems to be coming from the c2runtime.js and specifically the p.play function there, where it references A.Gain.Value (twice, near line 207). Removing all references to this seems to unbreak the game, though I don't know if it'll have any noticeable effects on the audio (since that's what the property seems to relate to.)
Look for these two references in c2runtime.js, both somewhere between lines 200-250
,this.A.gain.value=a*this.Lh
this.A.gain.value=c;
and remove them, and that appears to clear it up. (You might want to confirm that there aren't other references to 'A.gain' anywhere, in case this fix breaks them.)
I am working a website, and I'm trying to prevent the video file to be downloadable.
I've already prevented the right click function, and I've used a webiste called http://htmlobfuscator.com/ that allows the source code to be very difficult to decipher. The only issue I now have remaining is the inspect element feature on browsers. Does anyone know of any way to prevent this? I know that someone is always going to find a way to download or capture a video, but I'm just trying to limit the spread of my videos.
Thanks for your help,
Stephen
There is no actually way of completely stopping someone, you could however as some have mentioned use something like Vimeo or YouTube to minimize the downloading of your videos, or another way you could do it and have found from personal experience is either creating a login/register on your site to make someone signup to get your video thus minimizing how many can download it or you can encrypt the video with a password, i believe Vimeo has this option which requires someone to enter a password in before even viewing the video.
Yet these are just two ways to Minimize not completely stop.
There is no way to stop a browser's document inspector from finding your file's location. However, I am a recording musician, and I know of a few things you can do to make thieving more difficult.
Put your JS video location in an external file. Not a lot of protection here, but worthwhile enough to add.
Break up the video location into a few different JS variables. Your thief would at least need some basic JavaScript knowledge to get to the video location.
Use an obfuscater, like you did. (I LOVE HTMLObfuscator!)
You could use flash video. This is difficult to download, but slower viewing, and also a bit more difficult to create and host on your website.
The best thing to use is streaming video, but not everyone is able to do that either.
Good luck!
Here are some examples of what I mean:
google.com - focus is set on the "search" box
gmail.google.com - focus is set on the "user name" field (actually, most web email clients do this).
stackoverflow, ask a question - focus is set on the "title" box.
Sometimes, this is a convenient feature - e.g., on Google. From a usability standpoint, however, is it really considered a good feature to have on login pages?
Personally, I have often entered my user name, started to enter my password, then the page finished loading and had focus put back onto the user name field. Unfortunately, since I have complex passwords that force me to look at the keyboard while typing, I fail to notice when focus shifts. I often wind up typing my password in the unmasked user name field for anyone standing behind me to see.
Another situation, less dangerous but still annoying, is when I'm typing a url in my address bar while my homepage is still loading. As soon as it finishes, however, and if I'm not done entering the url, focus is stolen from me and put on some other field.
Should websites and/or browsers be programmed so that focus won't change if the user is already interacting with the site or the browser? Do problems like this bother ordinary (i.e., non-programmer) users?
These are really two separate questions with different answers:
Q: Should focus be given to the input field the user is most likely to use?
A: Most definitely yes, if "most users" really is 90% or more.
Q: Should this happen when the webpage finishes loading?
A: No. The "onLoad" event is a pretty stupid place to put this. The input field should get the focus as soon as it appears - it's usually completely irrelevant when the page finishes loading. Just put a <script> tag that sets the focus right after the input element itself.
I personally hate it when websites assume the focus. The main reason is that on my laptop, if I'm using the track pad and hit the backspace key it will automatically navigate back to the previous page. If focus has been placed on a textbox it will treat the backspace as tho I'm trying to delete a character.
My personal preference (and this has very little to do with best practice) is that it nothing should have initial focus, but the first tab will take it to the element that you want to have initial focus.
The same happened to me in Gmail, I find it slightly annoying, especially since it should be easy to circumvent:
In the OnLoad event handler, check if the input boxes (username or password) already contain text. If this is the case, do not change the focus.
As with all simple solutions, I would not be surprised if there were some strange side effects that render it unpractical, but I would give it a try anyway.
Oh, and if it works, why don't you send an email to Google? ;-)
That being said, I consider this behaviour a usability glitch, something that is not a bug, but slightly annoying. Don't annoy your customers. Fix it.
I think only we programmers have the habit of typing even before the page gets loaded ;-)
Most of the non-programmers friends I have wait till they see the "Completed" signal from the loading area.
But the 2 issues above are les annoying than having to move our mouse pointer/use tab everytime to type in what we want (username, password) in sites which do not have focus on a particular control.
"Should websites and/or browsers be programmed so that focus won't change if the user is already interacting with the site or the browser? "
I think browsers should be enabled to do this than the websites. Becauase it will be another trip back to server and can be frustrating for connections with low speed.
Overall I think this is just another minor issue/annoyance which we can live with. As I said only we programmers jump in type even before the page loads. Most of my friends dont know that they can type before the page gets loaded :)
There are sites where you acutally have one usecase a normal user uses keyboard for (normal user - as some, like me, use keyboard to navigate also). Sites like Google search actually expect you to just enter what you're looking for and hit enter.
Sites with multiple input areas and multiple exit paths though sometimes put initial focus somewhere too, and then it gets annoying. It gets even worse if they haev some odd tabbing order of their input areas - so they actually force you to use mouse.
I personally don't see the changing of focus when site finishes it's loading as an issue, not for a general user. But, as I mentioned, if it's really useful, it's a matter of what's the usecase in your particular application. And this might be a matter of showing the application in it's beta-stage to some people and performing usability tests.
Yes, focus should default to the most likely place for a user to start typing. Not doing so is textbook bad UI design.
When focus defaulting interferes with something you're already doing, this isn't an inherent problem of focus defaulting, it's a failure of an inadequate implementation. This, among other reasons, is why I put together a generic 'smart' autofocus script that does things like leaving you the hell alone if you've already started typing.
(Yes, I know it's hairy. Most of the hairiness is dealing with cross-browser issues -- a failing of Firefox, actually, for once.)