mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla-gemeenschap

Geoff Lankow: Can you imagine…

Mozilla planet - di, 18/08/2015 - 13:28

… an imaginary menagerie manager imagining managing an imaginary menagerie?

Just over two years ago, I posted about localizing Mozilla extensions. I'd made a website for translators, which automatically created GitHub pull requests. Well, I'm not here to say it's been an overwhelming success, but I think it did achieve my aim of simplifying the translation process.

Over the past month or so, I've rebuilt the website from scratch, to be much simpler, and much less fragile. Instead of having a Git clone on the webserver, and a working copy for every translation (which caused big headaches when it came time to update the clone), the website now stores translation data in a database, and when ready, creates files, commits, branches, and pull requests directly on GitHub. It also updates itself every time the original repo updates, by watching a particular branch. From a translator's point-of-view, not much has changed, although if they use GitHub to register, pull requests will be made using their account for better communication.

For reasons even I'm not really sure of, I called the original "Zoo". Now in a perfect storm of inspiration and originality, I've called this new website "Zoo2". Genius.

It's a little rough-around-the-edges, but it's ready to go. I'm looking for people to translate my extensions, obviously, but now I'm also looking for other extension writers willing to try things out. I have a few criteria, mostly around things I've yet to implement, but if your extension is on GitHub, open an issue and we'll talk. I'm also often in #developers on Mozilla IRC in the US evening/Asian day/European morning.

Edit: I'm hosting this thing on a free Heroku account, which means it must sleep for 6 hours a day (I'd get so much more done if I slept that little) and today's seen a lot of activity so it might be sleeping. I guess you get what you pay for, and I haven't paid anything yet.

Categorieën: Mozilla-nl planet

Byron Jones: happy bmo push day!

Mozilla planet - di, 18/08/2015 - 09:58

the following changes have been pushed to bugzilla.mozilla.org:

  • [1194584] “has cert” and “member of secure group” shouldn’t be visible when creating a user
  • [1181596] Modal UI doesn’t honor the “where to put the additional comment textarea” preference
  • [1193190] ‘view account history’ on edituser should include audit_log entries
  • [979441] Under mod_perl, some modules aren’t preloaded at startup
  • [981487] change bugs_fulltext from myisam to innodb
  • [1195315] Use of uninitialized value in string eq at Bugzilla/Product.pm line 99
  • [1195593] Able to delete any Bugzilla user’s Bugmail Filter
  • [1195598] The “unknown_action” error message could confuse the user
  • [1195620] stop sending http cookies to sentry
  • [1194250] ‘take’ button should uncheck “reset assignee to default”

discuss these changes on mozilla.tools.bmo.


Filed under: bmo, mozilla
Categorieën: Mozilla-nl planet

Mozilla testing very private browsing mode - The Register

Nieuws verzameld via Google - di, 18/08/2015 - 09:05

The Register

Mozilla testing very private browsing mode
The Register
The Mozilla Foundation has outlined plans for enhanced private browsing in its Firefox browser. The outfit thinks that “when you open a Private Browsing window in Firefox you're sending a signal that you want more control over your privacy than current ...
Mozilla Beefing Up Firefox Private BrowsingPC Magazine
Mozilla is testing an enhanced Private Browsing mode for future FirefoxInquirer
Mozilla Firefox Tests 'True' Private BrowsingInvestorplace.com
Christian Post -Computerworld -ZDNet
alle 141 nieuwsartikelen »
Categorieën: Mozilla-nl planet

Firefox - Mozilla testet neues Browser-Tool zum Schutz vor Tracking - OnlineWelten.com

Nieuws verzameld via Google - di, 18/08/2015 - 08:07

OnlineWelten.com

Firefox - Mozilla testet neues Browser-Tool zum Schutz vor Tracking
OnlineWelten.com
Die Verbesserungen, die Mozilla nun testet, blockieren aktiv die Elemente von Webseiten, die dazu verwendet werden könnten, die Nutzeraktivität über verschiedene Webseiten hinweg zu verfolgen. Dazu gehören auch verschiedene Inhalte, Analyse-Tools ...
Mozilla erweitert Privatsphäre-Modus von Firefox um Tracking-SchutzZDNet.de
Verbesserte Tarnkappe Mozilla will privaten Modus in Firefox erweiterncom-magazin.de
Mozilla erprobt Privatsphäre-Modus für FirefoxITespresso.de
HNA.de -WinBoard
alle 27 nieuwsartikelen »Google Nieuws
Categorieën: Mozilla-nl planet

Kevin Ngo: Using react-router with redux

Mozilla planet - di, 18/08/2015 - 02:00
Filler image! Atop Whistler Mountain near Vancouver, BC.

I'm working on submission and reviewer tools for FirefoxOS add-ons, which I'd like to shout out is the most exciting thing to hit FirefoxOS yet. It'll enable a customization community as powerful as CyanogenMod yet be much more accessible.

For this project, I wanted to port our Flux framework from Flummox to Redux while using react-router. I always struggle with getting react-router to pass Redux-related context to the handler components. Having done this twice and running into many pitfalls, I am sharing my experiences to prospective struggle-bus riders.

Note this guide will feature:

  • ES6 code
  • react@0.13
  • react-redux@0.9.0
  • react-router@1.0.0-beta1
  • redux@1.0.0

If you are behind on these versions, I recommend upgrading. The Flux community is moving very rapidly, so keep up.

app.js

Have your Redux store created. This is explained in the Redux documentation so I won't go into detail here. But I will note that we are using acdlite's redux-react-router library which conveniently makes availalbe react-router state inside of our Redux store, and features action creators for react-router.

import React from 'react'; import {Provider} from 'react-redux'; import {Route, Router} from 'react-router'; import {history} from 'react-router/lib/BrowserHistory'; import {combineReducers, createStore} from 'redux'; import {reduxRouteComponent, routerStateReducer as router} from 'redux-react-router'; import App from './components/App'; const reducer = combineReducers({ router: routerStateReducer, // ...other reducers. }); const store = createStore(reducer);

Next, imagine that App is our root-level handler component. We're going to need to wrap it with a Redux Provider such that it has access to the Redux store.

Why do we need to do this? We are using redux-react-router which should magically handle passing the Redux store as context into the handler component for us, but unfortunately react@0.13 does owner-based context which kills this feature. react@0.14 will do parent-based context so this will work in the future without need for wrapping. Owner-based context is also why we wrap our component in a function inside the Provider.

class ReduxApp extends React.Component { render() { return <Provider store={store}> {() => <App {...this.props}/>} </Provider> } }

Now let's build our Router and start the render:

React.render(<Router history={history}> <Route component={reduxRouteComponent(store)}> <Route name="app" path="/" component={ReduxApp}> // ...other routes. </Route> </Route> </Router>, document.querySelector('.app')); components/App.js

Our App component should now have access to the Redux store via context. Although, it is usually better practice to react-redux's connect to only expose a subset of the store. Let's see what the App component might look like:

import {bindActionCreators} from 'redux'; import React from 'react'; import {connect} from 'react-redux'; import {someApiFetch} from '../actions/someApi'; @connect( state => ({user: state.user}), dispatch => bindActionCreators({someApiFetch}, dispatch) ) export default class App extends React.Component { constructor(props, context) { super(props, context); if (this.props.user.loggedIn) { this.props.someApiFetch(); } } render() { return <div> <p>Logged in as {this.props.user.name}!</p> </div> } }

But that's out of the scope of this post. You can read more about implementing higher-level Redux components at react-redux. Hope this routes you in the right direction!

Categorieën: Mozilla-nl planet

Bobby Holley: MozPromise: A Better Tool for Asynchronous C++

Mozilla planet - di, 18/08/2015 - 02:00

Last time, I argued that shared mutable state should be considered harmful. To avoid it, threads need to own their data and communicate asynchronously.

The traditional approach to asynchronous programming involves a lot of callbacks: every potentially-asynchronous operation needs to bundle continuation logic as a callback function which gets invoked when the operation completes. This is great in theory, but in practice has a lot of downsides:

  • The control flow is scattered across the callbacks, making the program logic harder to follow. Worse, this difficulty scales linearly with the number of asynchronous operations, creating a perpetual disincentive to make more things asynchronous.
  • The control flow can end mysteriously when an API forgets to invoke the callback. Debugging these cases is much more painful than debugging a synchronous hang, because there’s no backtrace.
  • There tends to be a lot of boilerplate to marshall control flow in and out of messages, and this boilerplate can be easy to get wrong.

These problems span languages and runtimes, but are particularly visible in the Web Platform, whose run-to-completion model forces most interesting APIs to be asynchronous. After a lot of experimentation with different ways to improve the situation, Web developers recently coalesced around Promises as the prevailing idiom for managing asynchronicity. And while Promises certainly have their detractors, most people in the JavaScript community seem to agree that they were a good idea. So why don’t we have something like that in C++?

The answer is complicated. Recent editions of the C++ standard library include a thing called a Promise, but it doesn’t look much like a JavaScript Promise, in large part because C++ itself has no concept of an Event Loop. Gecko has one though, so last November I started building some machinery to mimic the idioms of JavaScript promises in our C++ multimedia stack. This became MediaPromise, was later renamed to MozPromise, and finally moved from dom/media/ to xpcom/.

MozPromises work great, and I already forget how we lived without them. A number of other organizations and researchers have been barking up the same tree this year, which indicates that we’ll likely see a lot more of this kind of thing very soon. The MozPromise API was a quick-and-dirty job, and I expect the industry will iterate on these patterns and eventually produce something more elegant and general. That being said, the core ideas of MozPromise have proven themselves to be exceedingly useful in enabling asynchronicity and parallelism, and I think they’re worth sharing.

The Basics

A method whose result may be computed asynchronously returns a MozPromise. More specifically, it returns an nsRefPtr<MozPromise<ResolveType, RejectType>>, which is templated on the type of values that we want to propagate upon success or failure. Returning a smart pointer directly from a method is generally frowned upon, but we do it anyway. This enables us to compactly follow the MozPromise-returning method with a Then() call, similar to what we’d do in JavaScript:

mProducer->RequestFoo() ->Then(mThread, __func__, this, &ThisClass::OnFooResolved, &ThisClass::OnFooRejected);

Then() takes a strong reference to a callback object (this in the case above), and guarantees that either OnFooResolved(ResolveType) or OnFooRejected(RejectType) will eventually be invoked as an asynchronous event on mThread. We pass __func__ here and elsewhere so that the built-in logging can print out the entire history of control flow (this turns out to be quite useful).

The above already offers several useful advantages over traditional callback-based asynchronicity:

  • The exact callback method is selected by the caller at call time, and not exposed to the underlying API at all. This eliminates boilerplate interfaces, enums, and all the other junk that’s normally needed to hook up and invoke a callback across loosely-coupled modules.
  • The callback is guaranteed to be invoked asynchronously on the thread that the caller intended, without any additional work on the part of the callee. This eliminates common re-entrancy and thread-safety pitfalls.
  • Hangs are easy to diagnose, because we have an object (the MozPromise) which tracks the request we made. The logging facilities make it simple to locate the caller that allocated the MozPromise, even when it’s buried deeply in unfamiliar code.
  • Mandatory first-class error handling.

Even with those advantages, the above code still requires the reader to jump to a different line to follow the control flow. This is often fine, but gets cumbersome when OnFooResolved is one or two lines of code. Fortunately, C++ lambdas allow us to support an alternate overload of Then() with inline callbacks:

mProducer->RequestFoo() ->Then(mThread, __func__, [...] (ResolveType aVal) { ... }, [...] (RejectType aVal) { ... });

Note that the resolve/reject values are always optional, so they may be omitted from the callback signature when unnecessary.

MozPromises are also chainable, provided that the types match up:

mProducer->RequestFoo() ->Then(mThread, __func__, [...] (ResolveType aVal) { ... }, [...] (RejectType aVal) { ... }) ->CompletionPromise() ->Then(mOtherThread, __func__, [...] (ResolveType aVal) { ... }, [...] (RejectType aVal) { ... });

This works much like you’d expect from JavaScript: the first callback can itself return a MozPromise, to which the second Then() is indirectly applied. Unlike JavaScript though, callers must explicitly invoke CompletionPromise() to access the thenable. This allows us to optimize some things in the common case where it isn’t needed. More importantly, it permits us to do something more interesting with the direct return value of Then() - more on that in the section on disconnection below.

InvokeAsync

The core difficulty of owned-data multi-threading comes when logic on thread A needs to interact with data owned by thread B. This is where MozPromise really shines, with the aid of a small helper called InvokeAsync:

InvokeAsync(mOtherThread, [MozPromise-Returning Method])->Then(...)

InvokeAsync dispatches a runnable to an arbitrary thread B to invoke a method that returns a MozPromise. Next, it returns a separate MozPromise of the same type to its caller on thread A. When the target method executes, the returned MozPromise is chained to the one that was returned to the caller on thread A, such that resolution and rejection are propagated through.

This allows for safe and transparent cross-thread procedure calls: thread A can invoke a method on thread B and use the result directly, whether or not A == B. In other words, MozPromises hide the details of message-passing and offer uniform, programmer-friendly ergonomics for same-thread and cross-thread procedure calls. This dramatically reduces the cost of dividing program logic across multiple threads, and puts the fruits of parallelism much more within reach.

Disconnection

MozPromise callbacks are cancellable up until the moment they are invoked, which is very powerful when you want to interrupt the operation of a long, asynchronous pipeline.

Consider the case of seeking a media element in Gecko. The request originates from a user action (manipulating the video controls), which invokes a setter on HTMLMediaElement on the Main Thread. This forwards request to the Decoder State Machine Thread, which queues up work on the Media Decode Thread, which is usually delegated to an OS-specific Platform Decoder Thread.

This presents a serious problem when the user interrupts the action and tries to seek somewhere else before the original seek has completed. There’s a lot of inertia in the pipeline, and we have no way to stop it instantaneously. The first operation may have already completed, and the result might already be on its way back, so we risk getting confused if we initiate a second operation.

So we ended up writing code like this:

mQueuedSeekTarget = newSeekTarget; mReader->DispatchCancelSeekTask(); // Wait for the previous seek to succeed or be canceled. // When everything is finished, we'll check mQueuedSeekTarget // and start seeking again. return;

This is clearly suboptimal, and we can do better with MozPromises.

I mentioned earlier that Then() does not return another MozPromise. This is because it returns a MozPromise::Request, which is a handle to the callback invocation scheduled by Then(). Callers that care can store this value, and invoke Disconnect() if they no longer wish to receive the callback. This allows us to handle interrupt seeks much more elegantly:

mSeekRequest.DisconnectIfExists(); mReader->DispatchCancelSeekTask(); // Move on with life \o/ mSeekRequest.Begin( InvokeAsync(mReader, &Reader::Seek) ->Then(...) );

We use disconnection heavily in Gecko’s media stack, and it is exceedingly useful in handling interruptions, error conditions, and shutdown.

Conclusion

MozPromises solved a lot of tricky problems for the Media Playback Team, and I’d encourage other Gecko hackers to give them a spin. I also welcome thoughts and feedback from the wider community of developers and theorists - I’m sure there are heaps of improvements to be made, and I would be especially interested in concrete suggestions that are practical to implement.

The latest version of the code can be found here, and a snapshot of the code at the time this piece was written can be found here. Patches welcome!

Categorieën: Mozilla-nl planet

Mike Conley: The Joy of Coding (Ep. 11): Cleaning up the View Source Patch

Thunderbird - za, 25/04/2015 - 23:22

For this episode, Richard Milewski and I figured out the syncing issue I’d been having in Episode 9, so I had my head floating in the bottom right corner while I hacked. Now you can see what I do with my face while hacking, if that’s a thing you had been interested in.

I’ve also started mirroring the episodes to YouTube, if YouTube is your choice platform for video consumption.

So, like last week, I was under a bit of time pressure because of a meeting scheduled for 2:30PM (actually the meeting I was supposed to have the week before – it just got postponed), so that gave me 1.5 hours to move forward with the View Source work we’d started back in Episode 8.

I started the episode by explaining that the cache key stuff we’d figured out in Episode 9 was really important, and that a bug had been filed by the Necko team to get the issue fixed. At the time of the video, there was a patch up for review in that bug, and when we applied it, we were able to retrieve source code out of the network cache after POST requests! Success!

Now that we had verified that our technique was going to work, I spent the rest of the episode cleaning up the patches we’d written. I started by doing a brief self-code-review to smoke out any glaring problems, and then started to fix those problems.

We got a good chunk of the way before I had to cut off the camera.

I know back when I started working on this particular bug, I had said that I wanted to take you through right to the end on camera – but the truth of the matter is, the priority of the bug went up, and I was moving too slowly on it, since I was restricting myself to a few hours on Wednesdays. So unfortunately, after my meeting, I went back to hacking on the bug off-camera, and yesterday I put up a patch for review. Here’s the review request, if you’re interested in seeing where I got to!

I felt good about the continuity experiment, and I think I’ll try it again for the next few episodes – but I think I’ll choose a lower-priority bug; that way, I think it’s more likely that I can keep the work contained within the episodes.

How did you feel about the continuity between episodes? Did it help to engage you, or did it not matter? I’d love to hear your comments!

Episode Agenda

References

Bug 1025146 – [e10s] Never load the source off of the network when viewing sourceNotes

Categorieën: Mozilla-nl planet

Meeting Notes: Thunderbird: 2015-04-21

Thunderbird - wo, 22/04/2015 - 05:00

Thunderbird meeting notes 2015-04-21. NOON PT (Pacific). Check https://wiki.mozilla.org/Thunderbird/StatusMeetings for meeting time conversion, previous meeting notes and call-in details

Attendees

ATTENDEES – put your nick 1. below 2. in comments unless explicit under round table 3. top right of etherpad next to your color

mkmelin, rolandt, pegasus, makemyday jorgk, rkent, gneandr, aceman, merike, Paenglab, wsmwk

Action items from last meetings
  • (rkent, Fallen) AMO addon compat: TheOne said that this late it is probably not worth doing at all. WIth so many other things for me to do, that sounds like a plan.
Friends of the tree
  • glandium, for fixing the various packager bugs that will help package Lightning (nominated by Fallen, who won’t be at the meeting)
Critical Issues

Critical bugs. Leave these here until they’re confirmed fixed. If confirmed, then remove.

  • (rkent) I am enormously frustrated by the inability to get two critical features landed in tb 38: OAuth and Lightning integration. Can we please give this very high priority?
    • OAuth integration: partial landing for beta 2, really REALLY critical that we get this finished.
  • In general, the tracking-tb38 flag shows what are critical issues. In the next week or so, that list will be culled to only include true blockers for the Thunderbird 38 release. There will still be many.
  • I don’t think we have a reasonable chance of shipping a quality release on May 12. More realistic is June 2.
  • We need to decide on how to do release branching. I am uncertain whether Lightning integration requires this or not.
  • Auto-complete improvements – some could go into esr31 (bug 1042561 included in TB38)
  • Lightning integration (below) really REALLY critical that we get this finished.
  • maildir UI: nothing more to do for UI, still want to land a patch for letting IMAP set this.
  • gloda IM search regressions: mostly fixed, some db cleanup necessary for users of TB33+ that nhnt11 will hopefully have ready to land soon.
    • aleth landed a fix to stop duplicated entries from appearing, nhnt11 will take care of the cleaning up the databases of Aurora/Beta/Daily users this weekend and keep us updated
  • bug 1140884, might need late-l10n

removing from critical list/fixed:

  • ldap crash bug 1063829: a patch in beta 37, beta results are unclear – not seen in 38
  • bug 1064230 crashes during LDAP search made worse by Search All Addressbooks bug 170270, needs tracking 38+ and review?rkent/jcranmer – not seen in 38
  • everyone should probably skim http://mzl.la/1DaLo0t version 31-38 regressions for items they can help fix or direct to the right people
Releases
  • Past
    • 31.6.0 shipped
    • 38.0b1 shipped 2015-04-03
    • 38.0b2 shipped 2015-04-20
  • Upcoming
    • 38.0b3 (when?)
Lightning to Thunderbird Integration

See https://calendar.etherpad.mozilla.org/thunderbird-integration

  • As underpass has pointed out repeatedly (thanks for your patience!) , we need to rewrite / heavily modify the lightning articles on support.mozilla.org. let me know irc: rolandtanglao on #tb-support-crew or rtanglao AT mozilla.com OR simply start editing the articles

Unfortunately not much progress because I was away. I hope to have the packaging bits done until the weekend. Glandium did a great job on the packager.py changes, hence I nominated him for Friends of the Tree. (fallen)

MakeMyDay should comment on the opt-out dialog, I think we should get it landed asap. bug 1130852 – Opt-Out dialog had some discussion on prefs

Round Table wsmwk
  • managed shipping of 31.6.0, 38.0b1, 38.0b2
Jorg K rkent
  • We have the beginnings of a business development group (rkent, wsmwk, magnus) that after signing NDAs will be given access to Thunderbird business documentation.
mkmelin
  • bug 1134986 autocomplete bug investigated and landed on trunk +++
aceman Question Time

— PLEASE INCLUDE YOUR NICK with your bullet item —

  • What happened to the Avocet branding? (Jorg K)
    • won’t be persued
  • Info about the meeting with Mitchell Baker on 20th March 2015, funding issues (Jorg K)
  • http://mzl.la/1O9khi4 can we get hiro’s bugs reassigned so the patches contained can get landed, and not lost? (wsmwk)
  • It would be great if some jetpack add-on support were available in thunderbird to share functionality with firefox and fennec. See also bug 1100644. No useful jetpack add-ons seem to exist for thunderbird (earlybird would be fine to use jpm over cfx). Are there any jetpack add-ons available to prove me wrong?

(pegasus) Is it worth looking at going to a 6-week release schedule to avoid the conundrum with getting not-quite-ready features in vs delaying?

Support team
  • Reminder: Roland is leaving Thunderbird May 12, 2015 after the release of Thunderbird 38: working on Thunderbird 38 plan and finally kickstarting Thunderbird User Success Council
    • looking for 3 people: English KB Article Editor, L10N Coordinator and Forum Lead. Is that you we’re looking for? If so email rtanglao AT mozilla.com or ping  :rolandtanglao in #sumo or #tb-support-crew
Other
  • PLEASE PUT THE NEXT MEETINGS IN YOUR (LIGHTNING) CALENDAR :)
  • Note – meeting notes must be copied from etherpad to wiki before 5AM CET next day so that they will go public in the meeting notes blog.
Action Items
  • wsmwk to pat glandium
  • wsmwk to email hiro’s bug list to tb-planning
  • rkent to review tracking list
Retrieved from “https://wiki.mozilla.org/index.php?title=Thunderbird/StatusMeetings/2015-04-21&oldid=1069635

Categorieën: Mozilla-nl planet

Rumbling Edge - Thunderbird: 2015-04-20 Calendar builds

Thunderbird - wo, 22/04/2015 - 04:17

Common (excluding Website bugs)-specific: (6)

  • Fixed: 1003196 – Add icons to more imip bar buttons
  • Fixed: 1137673 – extra divider in the options menu of new task dialog
  • Fixed: 1146500 – Wrong first occurrence for monthly recurrence with BYDAY and BYMONTHDAY
  • Fixed: 1150707 – Make use of tags for running only icaljs/libcal tests
  • Fixed: 1150882 – Lightning incorrectly unified after bug 1143163
  • Fixed: 1151404 – Nightly Windows x64 lightning hits 404 when updating

Sunbird will no longer be actively developed by the Calendar team.

Windows builds Official Windows

Linux builds Official Linux (i686), Official Linux (x86_64)

Mac builds Official Mac

Categorieën: Mozilla-nl planet

Rumbling Edge - Thunderbird: 2015-04-20 Thunderbird comm-central builds

Thunderbird - wo, 22/04/2015 - 04:16

Thunderbird-specific: (27)

  • Fixed: 768480 – Mac OSX TB 13 crashes in nsMsgDBFolder::CreateFileForDB when going online. Caused by folder subscribed on server that no longer exists?
  • Fixed: 849540 – Log in to Gmail (IMAP/SMTP) using OAuth in backend
  • Fixed: 939462 – Feature to count and show number of unread e-mails in subfolders should be optional. (because enumeration is slow)
  • Fixed: 1054308 – Investigate switching Thunderbird comm-central MozMill tests to mozharness
  • Fixed: 1118263 – C-C TB: JavaScript 1.6’s for-each-in loops are deprecated in accountprovisioner and about-support
  • Fixed: 1130852 – Add opt-out notification for calendar integration
  • Fixed: 1134234 – resource://app/modules/gloda/mimemsg.js should be resource:///modules/gloda/mimemsg.js in /mail/test/mozmill/shared-modules/test-message-helpers.js
  • Fixed: 1134986 – Address autocomplete sorting wrong – appears to ignore recent use (popularityindex) information in 31.4.0+
  • Fixed: 1138478 – ‘Write’ toolbar button disabled/greyed out after opening the menus in the Saved Files tab
  • Fixed: 1139524 – Font indicator doesn’t update when cursor is placed in text with this font
  • Fixed: 1140720 – Error reading font prefs in the Slovenian locale
  • Fixed: 1145970 – Port Bug 1005105 to TB [Remove noise from tab textures]
  • Fixed: 1145974 – Move more styles to shared addressbook.css
  • Fixed: 1147006 – TB shows instructions with [File] – [Offline] – [Synchronize] instead of [Download/Sync Now]
  • Fixed: 1147526 – Port Bug 1147311: migrateUI() should migrate font.language.group to a supported value
  • Fixed: 1148369 – “invalid ‘in’ operand colState” when switching folders
  • Fixed: 1148503 – TEST-UNEXPECTED-FAIL | toolkit/components/telemetry/tests/unit/test_TelemetryPing.js | xpcshell return code: 0
  • Fixed: 1149275 – Ensure newly opened conversations get focused
  • Fixed: 1150051 – C-C TB: EXCEPTION: formatted size is not numeric: ‘Read’
  • Fixed: 1150073 – C-C TB: Exception: Found visible column ‘correspondentCol’ but was expecting ‘recipientCol’!
  • Fixed: 1151223 – Reorder mail’s package-manifest.in to minimize differences to browser’s version
  • Fixed: 1152045 – Email address missing from “From” field on emails sent through Thunderbird 38 if the identityName pref was set
  • Fixed: 1152852 – Notification sound for highlights in chats not played if chat tab is selected, even when Thunderbird is not the currently active/focused application (in background)
  • Fixed: 1153511 – TEST-UNEXPECTED_FAIL | check-sync-dirs.py | build file copies are not in sync: differing file: ./win32/mozconfig.vs2013-win64
  • Fixed: 1153551 – Priority button : description missing
  • Fixed: 1154799 – “this._browser.messageManager is undefined” error just by starting Thunderbird
  • Fixed: 1156049 – Port ‘Bug 1155476 – Update sccache to 155c926′ to fix check-sync-dirs.py failure.

MailNews Core-specific: (30)

  • Fixed: 306035 – mail server appended to usernames with “@” (Password dialog for IMAP says <alias>@<domain>@<mailserver> instead of <alias>@<domain> on(at/…) <mailserver>)
  • Fixed: 662907 – web site from RSS feed not rendered correctly (due to noscript tags)
  • Fixed: 810495 – Make the classes which use the XPCOM nsISupports implementation macros final, to avoid the warning about deleting using a pointer to a base class with virtual functions and no virtual dtor
  • Fixed: 1123124 – Remove use of expression closures in mailnews/
  • Fixed: 1126607 – Kill the LDAP build system
  • Fixed: 1132218 – Update comm-central for PLDHashTable changes in bug 1131901
  • Fixed: 1139167 – Some birthdays are off by one day in Thunderbird’s addressbook
  • Fixed: 1139965 – Implement function to export addressbook in vCard format
  • Fixed: 1140652 – deduplicate some JS code writing out a simple string to a file in profile
  • Fixed: 1140884 – An error occurred while sending mail garbled
  • Fixed: 1141735 – unaligned labels in the LDAP server Advanced properties tab
  • Fixed: 1144621 – mimemsg.cpp might leak memory in some instances
  • Fixed: 1144719 – Allow the user to decide whether or not to use libnotify for new-mail alerts on Linux
  • Fixed: 1148887 – Message string for SMTP server connection error is incorrect. File: composeMsgs.properties, key: smtpSendRefused
  • Fixed: 1148888 – Message string for SMTP server connection error is incorrect. File: composeMsgs.properties, key: smtpAuthNotSupported
  • Fixed: 1148957 – Port bug 1148463 by backing out bug 1144128: temporarily disable new performance tools for Aurora uplift
  • Fixed: 1149247 – remove deprecated for-each-in loops in the account manager and account wizard
  • Fixed: 1150176 – Remove nsMemory::Alloc/Free/Realloc from c-c following their removal in bug 1134920
  • Fixed: 1150967 – Port Bug 1147839 to comm-central – Fix building installer on mingw by only including helper.exe if mknsisu is used
  • Fixed: 1150981 – Port Bug 674779 to comm-central – Add per-compartment CPU accounting
  • Fixed: 1151002 – Port Bug 1120308 to comm-central – [Presentation WebAPI] control protocol establishment and offer-answer exchange
  • Fixed: 1151181 – uninitialized error string in mailnews/extensions/mdn/src/nsMsgMdnGenerator.cpp
  • Fixed: 1152287 – TEST-UNEXPECTED-FAIL | crypto | Failed to find the appropraite data_path
  • Fixed: 1153187 – Build process is broken while reticulating splines “Variable SHARED_LIBRARY_LIBS” involved.
  • Fixed: 1153543 – when adding a new identity, the smtp server menulist is collapsed with no default item selected
  • Fixed: 1153557 – do away with preprocessing in am-identity-edit.js due to identity.autocompleteToMyDomain
  • Fixed: 1154468 – unused function getServerIdAndPageIdFromTree in am-identity-edit.xul
  • Fixed: 1155951 – Fix a non-array delete for scalars
  • Fixed: 1155953 – Remove Structurally dead code in nsNNTPProtocol.cpp
  • Fixed: 1155955 – remove a self assignment in nsImapUtils.cpp

Windows builds Official Windows, Official Windows installer

Linux builds Official Linux (i686), Official Linux (x86_64)

Mac builds Official Mac

Categorieën: Mozilla-nl planet

Mike Conley: Things I’ve Learned This Week (April 13 – April 17, 2015)

Thunderbird - zo, 19/04/2015 - 00:33
When you send a sync message from a frame script to the parent, the return value is always an array

Example:

// Some contrived code in the browser let browser = gBrowser.selectedBrowser; browser.messageManager.addMessageListener("GIMMEFUE,GIMMEFAI", function onMessage(message) { return "GIMMEDABAJABAZA"; }); // Frame script that runs in the browser let result = sendSendMessage("GIMMEFUE,GIMMEFAI"); console.log(result[0]); // Writes to the console: GIMMEDABAJABAZA

From the documentation:

Because a single message can be received by more than one listener, the return value of sendSyncMessage() is an array of all the values returned from every listener, even if it only contains a single value.

I don’t use sync messages from frame scripts a lot, so this was news to me.

You can use [cocoaEvent hasPreciciseScrollingDeltas] to differentiate between scrollWheel events from a mouse and a trackpad

scrollWheel events can come from a standard mouse or a trackpad1. According to this Stack Overflow post, one potential way of differentiating between the scrollWheel events coming from a mouse, and the scrollWheel events coming from a trackpad is by calling:

bool isTrackpad = [theEvent hasPreciseScrollingDeltas];

since mouse scrollWheel is usually line-scroll, whereas trackpads (and Magic Mouse) are pixel scroll.

The srcdoc attribute for iframes lets you easily load content into an iframe via a string

It’s been a while since I’ve done web development, so I hadn’t heard of srcdoc before. It was introduced as part of the HTML5 standard, and is defined as:

The content of the page that the embedded context is to contain. This attribute is expected to be used together with the sandbox and seamless attributes. If a browser supports the srcdoc attribute, it will override the content specified in the src attribute (if present). If a browser does NOT support the srcdoc attribute, it will show the file specified in the src attribute instead (if present).

So that’s an easy way to inject some string-ified HTML content into an iframe.

Primitives on IPDL structs are not initialized automatically

I believe this is true for structs in C and C++ (and probably some other languages) in general, but primitives on IPDL structs do not get initialized automatically when the struct is instantiated. That means that things like booleans carry random memory values in them until they’re set. Having spent most of my time in JavaScript, I found that a bit surprising, but I’ve gotten used to it. I’m slowly getting more comfortable working lower-level.

This was the ultimate cause of this crasher bug that dbaron was running into while exercising the e10s printing code on a debug Nightly build on Linux.

This bug was opened to investigate initializing the primitives on IPDL structs automatically.

Networking is ultimately done in the parent process in multi-process Firefox

All network requests are proxied to the parent, which serializes the results back down to the child. Here’s the IPDL protocol for the proxy.

On bi-directional text and RTL

gw280 and I noticed that in single-process Firefox, a <select> dropdown set with dir=”rtl”, containing an <option> with the value “A)” would render the option as “(A”.

If the value was “A) Something else”, the string would come out unchanged.

We were curious to know why this flipping around was happening. It turned out that this is called “BiDi”, and some documentation for it is here.

If you want to see an interesting demonstration of BiDi, click this link, and then resize the browser window to reflow the text. Interesting to see where the period on that last line goes, no?

It might look strange to someone coming from a LTR language, but apparently it makes sense if you’re used to RTL.

I had not known that.

Some terminal spew Some terminal spew

Now what’s all this?

My friend and colleague Mike Hoye showed me the above screenshot upon coming into work earlier this week. He had apparently launched Nightly from the terminal, and at some point, all that stuff just showed up.

“What is all of that?”, he had asked me.

I hadn’t the foggiest idea – but a quick DXR showed basic_code_modules.cc inside Breakpad, the tool used to generate crash reports when things go wrong.

I referred him to bsmedberg, since that fellow knows tons about crash reporting.

Later that day, mhoye got back to me, and told me that apparently this was output spew from Firefox’s plugin hang detection code. Mystery solved!

So if you’re running Firefox from the terminal, and suddenly see some basic_code_modules.cc stuff show up… a plugin you’re running probably locked up, and Firefox shanked it.

  1. And probably a bunch of other peripherals as well 

Categorieën: Mozilla-nl planet

Mike Conley: The Joy of Coding (Ep. 10): The Mystery of the Cache Key

Thunderbird - za, 18/04/2015 - 23:40

In this episode, I kept my camera off, since I was having some audio-sync issues1.

I was also under some time-pressure, because I had a meeting scheduled for 2:30 ET2, giving me exactly 1.5 hours to do what I needed to do.

And what did I need to do?

I needed to figure out why an nsISHEntry, when passed to nsIWebPageDescriptor’s loadPage, was not enough to get the document out from the HTTP cache in some cases. 1.5 hours to figure it out – the pressure was on!

I don’t recall writing a single line of code. Instead, I spent most of my time inside XCode, walking through various scenarios in the debugger, trying to figure out what was going on. And I eventually figured it out! Read this footnote for the TL;DR:3

Episode Agenda

References

Bug 1025146 – [e10s] Never load the source off of the network when viewing sourceNotes

  1. I should have those resolved for Episode 11! 

  2. And when the stream finished, I found out the meeting had been postponed to next week, meaning that next week will also be a short episode. :( 

  3. Basically, the nsIChannel used to retrieve data over the network is implemented by HttpChannelChild in the content process. HttpChannelChild is really just a proxy to a proper nsIChannel on the parent-side. On the child side, HttpChannelChild does not implement nsICachingChannel, which means we cannot get a cache key from it when creating a session history entry. With no cache key, comes no ability to retrieve the document from the network cache via nsIWebDescriptor’s loadPage. 

Categorieën: Mozilla-nl planet

Mike Conley: Things I’ve Learned This Week (April 6 – April 10, 2015)

Thunderbird - zo, 12/04/2015 - 16:50
It’s possible to synthesize native Cocoa events and dispatch them to your own app

For example, here is where we synthesize native mouse events for OS X. I think this is mostly used for testing when we want to simulate mouse activity.

Note that if you attempt to replay a queue of synthesized (or cached) native Cocoa events to trackSwipeEventWithOptions, those events might get coalesced and not behave the way you want. mstange and I ran into this while working on this bug to get some basic gesture support working with Nightly+e10s (Specifically, the history swiping gesture on OS X).

We were able to determine that OS X was coalescing the events because we grabbed the section of code that implements trackSwipeEventWithOptions, and used the Hopper Disassembler to decompile the assembly into some pseudocode. After reading it through, we found some logging messages in there referring to coalescing. We noticed that those log messages were only sent when NSDebugSwipeTrackingLogic was set to true, we executed this:

defaults write org.mozilla.nightlydebug NSDebugSwipeTrackingLogic -bool YES

In the console, and then re-ran our swiping test in a debug build of Nightly to see what messages came out. Sure enough, this is what we saw:

2015-04-09 15:11:55.395 firefox[5203:707] ___trackSwipeWithScrollEvent_block_invoke_0 coalescing scrollevents 2015-04-09 15:11:55.395 firefox[5203:707] ___trackSwipeWithScrollEvent_block_invoke_0 cumulativeDelta:-2.000 progress:-0.002 2015-04-09 15:11:55.395 firefox[5203:707] ___trackSwipeWithScrollEvent_block_invoke_0 cumulativeDelta:-2.000 progress:-0.002 adjusted:-0.002 2015-04-09 15:11:55.396 firefox[5203:707] ___trackSwipeWithScrollEvent_block_invoke_0 call trackingHandler(NSEventPhaseChanged, gestureAmount:-0.002)

This coalescing means that trackSwipeEventWithOptions is only getting a subset of the events that we’re sending, which is not what we had intended. It’s still not clear what triggers the coalescing – I suspect it might have to do with how rapidly we flush our native event queue, but mstange suspects it might be more sophisticated than that. Unfortunately, the pseudocode doesn’t make it too clear.

String templates and toSource might run the risk of higher memory use?

I’m not sure I “learned” this so much, but I saw it in passing this week in this bug. Apparently, there was some section of the Marionette testing framework that was doing request / response logging with toSource and some string templates, and this caused a 20MB regression on AWSY. Doing away with those in favour of old-school string concatenation and JSON.stringify seems to have addressed the issue.

When you change the remote attribute on a <xul:browser> you need to re-add the <xul:browser> to the DOM tree

I think I knew this a while back, but I’d forgotten it. I actually re-figured it out during the last episode of The Joy of Coding. When you change the remoteness of a <xul:browser>, you can’t just flip the remote attribute and call it a day. You actually have to remove it from the DOM and re-add it in order for the change to manifest properly.

You also have to re-add any frame scripts you had specially loaded into the previous incarnation of the browser before you flipped the remoteness attribute.1

Using Mercurial, and want to re-land a patch that got backed out? hg graft is your friend!

Suppose you got backed out, and want to reland your patch(es) with some small changes. Try this:

hg update -r tip hg graft --force BASEREV:ENDREV

This will re-land your changes on top of tip. Note that you need –force, otherwise Mercurial will skip over changes it notices have already landed in the commit ancestry.

These re-landed changes are in the draft stage, so you can update to them, and assuming you are using the evolve extension2, and commit –amend them before pushing. Voila!

Here’s the documentation for hg graft.

  1. We sidestep this with browser tabs by putting those browsers into “groups”, and having any new browsers, remote or otherwise, immediately load a particular set of framescripts. 

  2. And if you’re using Mercurial, you probably should be. 

Categorieën: Mozilla-nl planet

Pagina's