747123 - (layout-compat) Meta: Layout compatibility

Status: RESOLVED INACTIVE

(Tracking Graveyard :: Kilimanjaro, defect)

Description

[Lawrence Mandel [:lmandel] (use needinfo)]

There are 4 components to layout compatiblity:
1. UA Sniffing, aka not serving Gecko the right site
2. Use of webkit prefixed CSS properties without using the moz equivalent prefixed properties or where no moz equivalent property exists
3. Performance of CSS rendering and transitions
4. webkit/Android/Safari/other non moz specific JavaScript 

In order for the Web platform to be a draw we need a critical mass of apps that work well on Gecko. This meta bug tracks the requirements across evangelism, engineering, and QA to ensure layout compatibility.

More information and status can be found at
https://wiki.mozilla.org/Program_Management/Programs/Apps/Site_Compatibility

Comment 1

[Jason Smith [:jsmith]]

Per a recent email thread, this needs to get a better defined scope. A recent email thread indicated that items (1) and (2) was out of scope, but I disagree with that claim. The relevant parties applicable to this kilimanjaro tracker bug need to come to an agreement on kilimanjaro scope for web compatibility.

Comment 2

[Jason Smith [:jsmith]]

k9o Triage Strategy and On-going mobile web compatibility strategy is defined below. Feedback, comments, etc. is welcome and greatly appreciated.

k9o Triage

Evangelism bugs that affect top sites/apps that are linked to our top partners that BD has confidence we can work with them will be blockers for k9o. We need to take a look at our existing partner app problems logged and determine if they are k9o applicable or not. If you think a bug meets the k9o criteria (top site/app, linked to a top partner, BD has confidence in communication with them), then nominate the bug for k9o. To get experience with this process, we may want to schedule an example triage session for ourselves to get experience with this. Then, we can handle it going forward on a case by case basis.

On-going Strategy to Resolve Top Partner App/Site Issues

If an evangelism bug gets marked as a k9o blocker, then we must try to build our data for what the problems are with the site and send that off to the partner. We'll need to work with them to see if we can get the problems resolved. If the problems do get resolved, we'll need to verify that they are fixed. If they don't get resolved in a certain amount of time, then we'll need to make a judgment call if there something we can do internally (e.g. support X webkit property) to fix the problem or determine if it's still a k9o blocker.

Note - Issues that are not marked as k9o blockers could still be important, so we'll need to handle what we do with them on a case by case basis. It could be that non-k9o blockers are worked on when there are no k9o blockers open that require work on our end.

Comment 3

[Tony Chung [:tchung]]

(In reply to Jason Smith [:jsmith] from comment #2)
> k9o Triage Strategy and On-going mobile web compatibility strategy is
> defined below. Feedback, comments, etc. is welcome and greatly appreciated.
> 
> k9o Triage
> 
> Evangelism bugs that affect top sites/apps that are linked to our top
> partners that BD has confidence we can work with them will be blockers for
> k9o. We need to take a look at our existing partner app problems logged and
> determine if they are k9o applicable or not. If you think a bug meets the
> k9o criteria (top site/app, linked to a top partner, BD has confidence in
> communication with them), then nominate the bug for k9o. To get experience
> with this process, we may want to schedule an example triage session for
> ourselves to get experience with this. Then, we can handle it going forward
> on a case by case basis.
> 
> On-going Strategy to Resolve Top Partner App/Site Issues
> 
> If an evangelism bug gets marked as a k9o blocker, then we must try to build
> our data for what the problems are with the site and send that off to the
> partner. We'll need to work with them to see if we can get the problems
> resolved. If the problems do get resolved, we'll need to verify that they
> are fixed. If they don't get resolved in a certain amount of time, then
> we'll need to make a judgment call if there something we can do internally
> (e.g. support X webkit property) to fix the problem or determine if it's
> still a k9o blocker.
> 
> Note - Issues that are not marked as k9o blockers could still be important,
> so we'll need to handle what we do with them on a case by case basis. It
> could be that non-k9o blockers are worked on when there are no k9o blockers
> open that require work on our end.

For others to see my question via irc:

tchung: only one quesiton
[4:46pm] tchung: where do we broadcast to triagers/bug filers, what a topapp/site is?
[4:46pm] tchung: a few of us in the circle will know, but not sure its listed anywhere else (or would appropriately be so)
[4:46pm] jsmith: tchung: We could link a document or wiki on the bug
[4:46pm] jsmith: tchung: Lawrence has a wiki on site compatibility
[4:47pm] tchung: then that would be fine
[4:47pm] tchung: as long as people know where to reference
[4:47pm] tchung: so they know how to nom or triage

Comment 4

[Jason Smith [:jsmith]]

Update on plan identified on comment 2 below based on Jean-Yves's feedback to include layout team processes in the strategy earlier in the on-going strategy cycle.

k9o Triage

Evangelism bugs that affect top sites/apps that are linked to our top partners that BD has confidence we can work with them will be blockers for k9o. We need to take a look at our existing partner app problems logged and determine if they are k9o applicable or not. If you think a bug meets the k9o criteria (top site/app, linked to a top partner, BD has confidence in communication with them), then nominate the bug for k9o. To get experience with this process, we may want to schedule an example triage session for ourselves to get experience with this. Then, we can handle it going forward on a case by case basis.

On-going Strategy to Resolve Top Partner App/Site Issues

If an evangelism bug gets marked as a k9o blocker, then we must try to build our data for what the problems are with the site and send that off to the partner and work with them if they have questions. Additionally, for problems that are high priority in the layout engine, we then notify the layout team of the webkit properties being used in high priority problems of that site. Working with them, we determine if the value to implement temporary webkit support for the property exceeds the cost by looking at factors such as past top site/app testing, the effort to implement the webkit property, and frequency of use through John Jensen's CSS compatibility reports. We additionally move forward to try standardize the properties that are causing the high priority problems through working with the layout team. If the issues don't get resolved in a certain amount of time, then we need to re-evaluate our strategy for those issues and determine if those issues are still k9o blockers.

Comment 5

[[e-mail] [:onecyrenus]]

Could we link this bug to what our top sites / apps / partners are for k9o?

Comment 6

[Jason Smith [:jsmith]]

(In reply to [e-mail] from comment #5)
> Could we link this bug to what our top sites / apps / partners are for k9o?

I don't know if we can do that, as Ron in the past has been against publicly announcing that information. Lawrence has the list in hand though, so it's easy to find out when needed.

Comment 7

[[e-mail] [:onecyrenus]]

So are you are advising that until we know what our top apps / sites are for Brazil then work does not continue on the issues Lawrence mentioned in comment #1. 

The logic is fairly circular in that "evangelism" bugs cannot be k9o blockers because top apps for the u.s market are no longer k9o blockers, and the top apps for the Brazil market are unknown. 

Then you could take the reasoning a step further and say if there are no evangelism bugs then none of the issues listed in Comment #1 are issues that need addressing.

Comment 8

[[e-mail] [:onecyrenus]]

The next step would of course then be to mark the bug invalid.

Comment 9

[Lawrence Mandel [:lmandel] (use needinfo)]

Backing up to the question in comment 5, the current target list for sites is the Alexa top 50 for Brazil. We should work off this list. I have started a summary at
https://wiki.mozilla.org/Program_Management/Programs/Apps/Site_Compatibility/TopListBrazil

We do not yet have any specific apps to target for the Brazilian market. I have reached out to business development to get a list of target apps. (I expect that some of the sites on the list above will become apps in the market.) For any partner apps, I expect that specific problems encountered during the development of apps will be communicated to business development and that bugs will be filed in bugzilla.

Comment 10

[Eric Shepherd [:sheppy]]

Please ensure that any dependencies that may affect developer docs have the dev-doc-needed keyword on them.

Comment 11

[Lawrence Mandel [:lmandel] (use needinfo)]

This bug has a number of dependencies for global Web properties. It may be better to create another tracking bug for basecamp that focuses on the top properties for the Brazilian market.

Comment 12

[Marco Castelluccio [:marco]]

http://bugs.horde.org/ticket/11216

Comment 13

[Sylvestre Ledru [:Sylvestre]]

Closing inactive bugs in Tracking::Kilimanjaro