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.
Related
I'm attempting to learn web development, and I'm taking an online course from udemy. I am still in the html coding stage and I don't get the correct attributes auto suggested when I type in "form" (without the quotes). I get this:
When the instructor does it, this is the result:
I'm certain I used to get the result the instructor got, but I don't now. I rolled back to version 1.33 of VS Code but that didn't help.
Any suggestions? I appreciate any and all help you can provide but please don't assume I can navigate to whatever setting needs to be changed Please provide the full path to allow me to get there! Thanks again.
So I just downloaded and installed Atom. When you type form and hit tab you get three attributes: class, action and method. I wonder why the defaults are different between the two editors. I prefer VS Code just for the visual appearance of it, and it seems to be the one everyone uses, but why the difference and is there a way to make them the same?
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.)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
IS there a way to test CSS and HTML? For instance: sometimes some of the notices get affected by some CSS changes. I don't want to be testing all the notices by hand every time I do a change.
Thanks
It's very difficult to automate testing of layout. But it's not too difficult to drastically cut down the time and effort involved so that you can do it manually, but very quickly.
You could try Blink Testing.
I've heard of it used for websites like this.
Write a script that walks through your website, visiting as many pages as you can think of.
At each page, take a screen shot.
Combine all the screen shots into a 'movie' with just a second or two for each screenshot.
Now, each day you can 'play' the movie and watch it for any issues.
You could even extend bcarlso's approach but replace the MD5 check with a visual check. Each page gets displayed for 1 second - first the known good, then the new. You could alternate them a few times so any obvious errors will appear as a flicker.
A website with hundreds of pages can be checked like this in a matter of a few minutes. You may not think this will provide enough time to find issues, but it is remarkably efficient in identifying obvious problems with your website.
Any pages that have major layout problems will pop out at you as they don't match the same pattern as all the other pages.
I am assuming that the issue that you're trying to test would be that the CSS changed in some incompatible way with the layout causing, for example, text to be truncated or otherwise visually "broken". If that's the case, then I would say that there isn't a good way to test the aesthetics of a page at this time. One of the primary benefits of TDD and CI is quick feedback so that you know something is broken before it gets to production. Not knowing much context around your environment and how those changes make it into your app it's hard to suggest solutions, but here is an example of a potential non-traditional option:
Put a commit hook into your repository that let's everyone on the team know via an e-mail when someone changes some CSS. Preferably with a diff of the CSS. This would give the team a heads up to keep an eye out for layout problems.
We started an experiment to use WATIR to walk some of the main screens in the app and take a picture using ImageMagik (essentially a screenshot) and store it in a "Last Known Good" folder. Every day re-run the script on a clean install of the app and data and place the images in a "Current" folder. At the end of each run use an MD5 to compare the images and alert on changes. Have the QA team review a list of flagged screenshots and if the change was acceptable (for example, a field was added as part of a feature) then copy "Current" to "Last Known Good". Unfortunately we didn't get our experiment finished so I don't know if it will work well. I'm concerned about the brittleness of screenshots as "assertions".
Hope that helps!
I believe Selenium can test your frontends for you. Specifically for browser compatibility testing, take a look at Selenium RC.
If you'd simply like to make sure you're contents are in the right contents etc. etc. you can create a simple testing suite that's going to be making GET requests to your website. When you receive all the content you can run it through a validation template like xslt. Well formed html will usually be able to be matched against xslt's or xsd's. It is not ideal but if you're only worried about the structure of your website and not the styling you'll be able to achieve it this way.
A change to CSS should not affect the behaviour of a page, only it's appearance, so I'm not sure that Selenium would be much help for this.
I'm going to take a guess that you are trying to avoid problems such as elements being misplaced on the page so that they are not readable. If so, you would probably need some kind of OCR-based tool, but I don't know one off-hand to suggest.
However, it may be to better to invest your effort in preventing this kind of problem in the first place. If your layout is easily broken, maybe you need to refactor your CSS to something simpler.
I have worked a few places which haven’t used source control. They seemed to get into the habit of putting comments around code they changed explaining the change so that things could be reverted.
I have found that this makes the code very difficult to read, and have been fairly adamant that such comments are not needed after introducing source control as the revision history will let you match up tickets with changes.
However now, I am not so sure, I think it may be good to document major revisions to a file in a file as well as in the commit messages. This should make the code more readable. Do people have a best practices way of documenting changes to code, so that it is not too cluttered but is still explanatory to someone trying to read it?
Just to be clear, I am not talking about a list of changes in the head of the file (which is a whole other argument) but comments in the code.
Most source control systems have an "Annotate" or "blame" command. It shows what code changed with each revision.
Since this information does not change the behavior of the program, or make it easier to understand the program, it doesn't belong in the program.
The documentation present in code should describe the code it is near. If the code changes, the documentation should also change accordingly. The version control system should take care of managing what changed and why it changed. Let the code and it's documentation do it's job (Doing things, and describing how/why those things are done), and let the version control system do it's job (controlling/documenting versions and changes).
Whenever you start indicating history in the present(current code), you are asking for trouble. Just think what a particularly change-heavy area of code would look like if it had a number of changes?!
If the comment is time sensitive don't do it it's a bad idea. Put a comment on the source file in the version control system instead.
I see this problem all the time at work. The code base I am currently working on extends back to 1979. You can imagine the difficulty with comments like the one below which have built up over that time:
"Line below seems to fix bug xyz, will revert if unforseen issues occur"
I realise it's not a very descriptive comment in the first place but that sort of thing in svn/cvs/etc. is actually very handy. A comment like that in the code sows the seeds of doubt. Can the comment be removed? Is the unforseen issue that has caused me to have to look back at the code related to this comment? etc.
I'm just wondering how knowing what the program USED to do helps understanding it now? You say it aids readability. How?
Now, when something is changed because the old way didn't work and the new way is counter-intuitive, I think that should be commented in code, because it's necessary to know for all time "This didn't work, don't do it again. I know it looks like it would make more sense. Still don't do it." Otherwise, I don't see that it helps.
Don't think that commenting changes inside a code is ever possible in a explanatory way.
But I'd like to say about "Modification history at the file begin". I doubt that this is useful at all. Unless I wanted to know which to versions of a file to compare to see the difference that were introduced with some "NNNN" task. In the file begin there is a line "NNNN date - small description". And our source control can "say" who and in which version this line was introduced.
So without this line I would look through all versions to find correct one.
I think it's good to document major changes or refactorings as comments in the code. I agree that it does get a little messy to read around copious amounts of comments, but I think it's easy enough to ignore the comments and try to just read the code. If anything is confusing, or you are tempted to change something, and there is a comment near by, you will be much more inclined to read the comment, as opposed to doing diffs with previous versions to see what had changed and why.
Each method in our codebase has its own change history. When the code of a method is changed its header gets a new entry. The code itself does not get cluttered with history comments, only the method header. Each change history entry consists of one or two lines briefly describing the reason for the code change in general terms. The entry also contains a number that refers to a change document, The change document also contains links to bug reports, development projects, design documents etc.
Such entries are invaluable, as they often give you an insight as to why the code is as it is. If you are there to fix a bug the history trace will invariably tell what code change introduced the bug, what the change was attempting to do, and therefore what else you need to be aware of when deciding on a fix.
OTOH - Reams of comments in the body of the code describing what it does and who changed it when are just noise.
Going to have a stab at answering this myself.
Documenting every change in the source makes it difficult to read, however if there is a particularly counterintuitive piece of code in there and it was introduced for a particular ticket put a note by it as to why the code is strange.
But the code should still be documented. So while you make not put in
/* ticket 101: add blink tag to headers, JF - 20010102 */
You may want to put in
/* make headers blink */
Quite often when people stop doing the former type of comments, they cut down massively on their comments and this is bad.