Closed Bug 748253 Opened 8 years ago Closed 8 years ago

Lord of Ultima -moz-border-image does not render on buttons for FF 13 Aurora & FF 14 Nightly - Works on FF 12 Beta 6

Categories

(Tech Evangelism Graveyard :: English US, defect)

defect
Not set

Tracking

(firefox12 unaffected, firefox13+ unaffected, firefox14+ verified)

RESOLVED FIXED
Tracking Status
firefox12 --- unaffected
firefox13 + unaffected
firefox14 + verified

People

(Reporter: jsmith, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [topapps], [website-compatibility], [marketplace-beta=])

Attachments

(5 files, 1 obsolete file)

Steps:

1. Go to lordofultima.com
2. Login with an account
3. Start a new game
4. Select Quit Tutorial

Expected:

The ok and cancel buttons should render the border image specified in the style rules:

-moz-border-image("http://prodcdngame.lordofultima.com/cdn/351369/resource/webfrontend/theme/form/button.png")

Actual:

On FF 13 Aurora & FF 14 Nightly, the border image does not render on the buttons. This is different behavior than the FF 12 Beta 6 - It does render the border image on the buttons. Sounds like a regression.
Keywords: regression
What does the actual CSS look like?  What's quoted in comment 0 isn't a valid way to use -moz-border-image.

Chances are, this is a result of bug 497995, but it really depends on exactly what the CSS on the site looks like.....
My bad. Copied and pasted it incorrectly. Here's the right CSS for a button in that game:

-moz-border-image: url("http://prodcdngame.lordofultima.com/cdn/351369/resource/webfrontend/theme/form/button.png") 10 10 10 10 stretch stretch; position: absolute; line-height: 0; font-size: 0pt; overflow: hidden; -moz-box-sizing: border-box; border-width: 10px; top: 0pt; left: 0pt; pointer-events: none; width: 67px; height: 27px; z-index: 5;
Thanks.

So looking at the spec, this border-image style does not specify fill, so it should not be drawn over the background, just over the actual border area.  But the styles there don't specify a border-style, and the default is "none".  So unless there are some other styles that set the border-style there is no border, and nothing gets drawn.

Note that before we fixed bug 497995 the presence of border-image would override a "border-style: none", but the current spec draft clearly says:

  The border-image properties do not affect layout: layout of the box, its content, and
  surrounding content is based on the ‘border-width’ and ‘border-style’ properties only. 

Does editing that CSS to include "border-style: solid" fix things, by any chance?
Whiteboard: [topapps]
I asked Thomas to reach out to them on this already; it's broken in Aurora too.
(In reply to Justin Scott [:fligtar] from comment #6)
> I asked Thomas to reach out to them on this already; it's broken in Aurora
> too.

Still puzzled as to why it works on FF 12 Release, but it does not work on FF 13 Beta & 14 Nightly. Is this really an evangelism bug here? Or a bug in the gecko layout engine?
See comment 5: In the Firefox 13 cycle we changed the behavior of -moz-border-image to align with some spec changes.  That happened in bug 497995.

Again, does adding a border-style:solid to the element fix the rendering of the page?
(In reply to Boris Zbarsky (:bz) from comment #8)
> See comment 5: In the Firefox 13 cycle we changed the behavior of
> -moz-border-image to align with some spec changes.  That happened in bug
> 497995.
> 
> Again, does adding a border-style:solid to the element fix the rendering of
> the page?

Nope. If I add border-style:solid to the element, the button image doesn't show. If I hover over it, it shows partially (see screenshot attached), but does not paint over the entire button area.
Attached image Border Style Solid LoU
Jason, does saving the page as "web page, complete" give you something that still shows the bug?  If so, would you be willing to attach it here?
Attached file Lord of Ultima Zip Files (obsolete) —
(In reply to Boris Zbarsky (:bz) from comment #11)
> Jason, does saving the page as "web page, complete" give you something that
> still shows the bug?  If so, would you be willing to attach it here?

Attached files. I changed the CSS in the inspect editor to include border-style: solid, then saved as web page complete. Opening the resulting web page saved will not show even the image button border at all on hover (it never comes up).
FYI - The partner knows of this problem now. We need to address this issue soon, both from what we need to fix internally and what the partner needs to do.

- Layout team - Is this a bug on your end based on the information provided? If so, what needs to be fixed?
- Evangelism - Are we suggesting the developer to include border-style:solid where they use -moz-border-image? Is there anything else that stands out that needs to change?
(In reply to Jason Smith from comment #13)
> (In reply to Boris Zbarsky (:bz) from comment #11)
> > Jason, does saving the page as "web page, complete" give you something that
> > still shows the bug?  If so, would you be willing to attach it here?
> 
> Attached files. I changed the CSS in the inspect editor to include
> border-style: solid, then saved as web page complete. Opening the resulting
> web page saved will not show even the image button border at all on hover
> (it never comes up).

And does that attached testcase work correctly in Firefox 12?
Attachment #617986 - Attachment is obsolete: true
(In reply to David Baron [:dbaron] from comment #15)
> (In reply to Jason Smith from comment #13)
> > (In reply to Boris Zbarsky (:bz) from comment #11)
> > > Jason, does saving the page as "web page, complete" give you something that
> > > still shows the bug?  If so, would you be willing to attach it here?
> > 
> > Attached files. I changed the CSS in the inspect editor to include
> > border-style: solid, then saved as web page complete. Opening the resulting
> > web page saved will not show even the image button border at all on hover
> > (it never comes up).
> 
> And does that attached testcase work correctly in Firefox 12?

The attached test case does not work in FF 12, as it was generated from FF 13 which had the bug. I just tried the opposite:

- Generated the web page complete test case from FF 12
- Ran the index page on FF 12 - Buttons show up correctly
- Ran the index page on FF 13 - Buttons do not show up correctly

Important note - this error does not just occur on the okay or cancel buttons, it occurs all over the place in this game. See the screenshots for comparison.
Whiteboard: [topapps] → [topapps], [website-compatibility]
Attached file Lord of Ultima - FF 13
Jason, thanks for attaching those pages!

> The attached test case does not work in FF 12, as it was generated from FF 13

OK.  So a good question there is why that's the case.  We need to figure that out.  How are the testcases different?

Looking at the "Lord of Ultima Zip - FF 12" attachment, if I change the styles for the relevant divs in two ways:

1)  Add "border-style: solid"
2)  Add "fill" after the "10 10 10 10" in the -moz-border-image style

then the rendering in Firefox 13 is the same as it is on the unmodified page in Firefox 12/
> So a good question there is why that's the case. 

The version saved from Firefox 13 doesn't have a -moz-border-image style at all.  Are you seeing CSS parse errors for -moz-border-image when you load the page in Firefox 13, or is the site sending different markup?

In any case, the two items from comment 19 are definitely evangelism.
Though if bug 713643 gets sorted out as hoped, the 'fill' should only be needed on the 'border-image' and not the '-moz-border-image'.
(In reply to Boris Zbarsky (:bz) from comment #20)
> > So a good question there is why that's the case. 
> 
> The version saved from Firefox 13 doesn't have a -moz-border-image style at
> all.  Are you seeing CSS parse errors for -moz-border-image when you load
> the page in Firefox 13, or is the site sending different markup?

Are you sure? Just double checked that zip file - I'm seeing -moz-border-image being used.

> 
> In any case, the two items from comment 19 are definitely evangelism.

Confirmed that will fix the buttons.
If the required fixes are implemented in bug 497995 that are causing it to get backed out repeatedly (just saw that bug's target milestone moved to FF 14), will it resolve the issues with the Lord of Ultima page with moz-border-image?

What I'm trying to figure out is:

What are the required evangelism efforts vs. work-arounds to get around known issues in bug 497995's implementation
> Are you sure?

Ah, interesting.  I'd been looking in DOM inspector, which showed the styles for the "Firefox 12" zip file but not the "Firefox 13" zip file.

When viewed in a text editor, in the "Firefox 12" zip file I see things like:

  -moz-border-image: url(something) 8 8 8 8 stretch stretch;

while in the "Firefox 13" zip file I see things like:

  -moz-border-image: url(something) 8 8 8 8 / 1 1 1 1 / 0 0 0 0 stretch stretch;

The latter syntax is the new one and Firefox 12 doesn't understand it, so I can see why I was coming up with nothing in Firefox 12 in the DOM Inspector.  Not sure what's going on with Firefox 13 there; looking into that.

The fact that they're clearly sniffing 12 vs 13 already should help them deploy the fix from comment 19 too...
On the other hand, the "1 1 1 1 / 0 0 0 0" thing may just be the different serialization in fx13, come to think of it, so maybe they're not sniffing at all.

I just tested again with Firefox 13 on the page saved from Firefox 13, and adding the border-style and the fill works there too.  I'm not sure what I was seeing before...

So I think the point is that the site needs to add the border-style and the fill.  It needs to add the border-style no matter what.  It needs to add fill to "border-image" no matter what and to "-moz-border-image" if we don't get bug 713643 fixed (though given that it landed on beta earlier today, the chances of it not being fixed seem low).

I'm not sure what the answer to the question in comment 23 is, and to what extent the patch that landed earlier today affects it.  David?
Assignee: nobody → english-us
Component: Layout: Images → English US
Product: Core → Tech Evangelism
QA Contact: layout.images → english-us
Version: 13 Branch → unspecified
Analyzing bug 730530, sounds like this issue happens in more than one EA game.
Blocks: 497995
The plan is to keep backing out the first set of border-image changes until we can land the second... though that might become harder.

There shouldn't be too much to finish for the second round, really, but I should be working on font inflation instead.
Whiteboard: [topapps], [website-compatibility] → [topapps], [website-compatibility], [marketplace-beta?]
Marking marketplace-beta- since I spoke to BD and they are engaged with the partner on a work around. However, we do need to get a ETA for a fix on this. I'm not sure who to ask for that.
Whiteboard: [topapps], [website-compatibility], [marketplace-beta?] → [topapps], [website-compatibility], [marketplace-beta-]
Whiteboard: [topapps], [website-compatibility], [marketplace-beta-] → [topapps], [website-compatibility], [marketplace-beta=]
Duplicate of this bug: 750329
It's unclear at this point if FF13 is affected. Tracking for that release and asked for clarification in https://bugzilla.mozilla.org/show_bug.cgi?id=497995#c69
To clarify, what I should tell the partner is below, correct? Could someone please review and tell me if this is okay?

Hi,

The syntax for moz-border-image is undergoing changes in an upcoming Firefox release (https://developer.mozilla.org/En/CSS/border-image), currently targeted to be implemented by Firefox 14. We have noticed that two EA games (Command and Conquer Tiberium Alliances and Lord of Ultima) will be affected by this change, as the images being used may not be rendered correctly. To fix this issue, we would suggest that you add the following CSS lines of code to when you are using moz-border-image:

- Add border-style:solid in the same place moz-border-image is used
- Include fill after -moz-border-image numerical references

Example from Lord of Ultima:

-moz-border-image: url("http://prodcdngame.lordofultima.com/cdn/351369/resource/webfrontend/theme/form/button.png") 10 10 10 10 / 1 1 1 1 / 0 0 0 0 fill stretch stretch; position: absolute; border-style: solid; line-height: 0; font-size: 0px; overflow: hidden; -moz-box-sizing: border-box; border-width: 10px; top: 0px; left: 0px; pointer-events: none; width: 56px; height: 27px; z-index: 5;

Let me know if you have any questions.

Sincerely,
Jason Smith
I think we should probably refrain from making contact until bug 713643 lands.
Blocks: 713643
(In reply to David Baron [:dbaron] from comment #32)
> I think we should probably refrain from making contact until bug 713643
> lands.

Gotcha. I'll mark the other bug as important to verify. After that, I'll re-evaluate this bug for what we need to say to the partner.
No, I mean until the *fix* lands, not until we back out the original change again.
No longer blocks: 713643
Depends on: 713643
Do we know when Bug 713643 will land?
So what should we do in the short-term? I'd rather not leave the developer hanging for a while for a response. If there is something immediately they can do, then I think it be worth mentioning.
No longer blocks: 497995
Depends on: 497995
(In reply to Jason Smith [:jsmith] from comment #37)
> So what should we do in the short-term? I'd rather not leave the developer
> hanging for a while for a response. If there is something immediately they
> can do, then I think it be worth mentioning.

I will make a tentative reply to your question.

I think we should ask the developers to do the following.

1) set border-style:solid
2) set -moz-border-image to the old value (will allow to work with any released Firefox version as long as bug 713643 does not land).
3) set border-image to the new value (will allow to work with any future version of Firefox once bug 713643 does land (as it drop prefix at the same time)

This shouldn't have negative effect on the game on another browser as they use their own prefixed property (overriding border-style very likely). If another browser drop the prefix before us, the unprefixed version will work for it too as it is standard-compliant.

Once bug 713643 lands and ESR 10 is EOL, we can drop point 2.

Note: you can also tell them that with this change, this part of their code will be future-proof, too.

David, Boris can you confirm/infirm the correctness of the proposal?
Note that with this plan, the game won't work on _non-released_ Firefoxen (at least Nightly and Aurora, as the back-out usually happen before Beta) as long as bug 713643 is not fixed.
(In reply to Jean-Yves Perrier [:teoli] from comment #39)
> 1) set border-style:solid

... and set border-width correctly (rather than setting it in -moz-border-image as the old syntax allowed)

> 2) set -moz-border-image to the old value (will allow to work with any
> released Firefox version as long as bug 713643 does not land).

Yes.

> 3) set border-image to the new value (will allow to work with any future
> version of Firefox once bug 713643 does land (as it drop prefix at the same
> time)

We shouldn't go around asking people to do this until there's actually an implementation they can test in.  Otherwise they're likely to get it wrong.  (Once bug 713643 lands there will be such an implementation.)
David, I do understand. That makes great sense (from a technical perspective). This should even be opposed to us by their Web developers.

From an evangelization perspective, this leads to the unfortunate case where reaching them before we drop a prefix is less effective, even if a spec reached CR (and we can reach them with a much stronger position: do it once and it will work in the future in any compliant browser).

I'm especially concerned that if we have to reach the same Web sites/Apps several times in a short period, it may lead to a "Firefox-specific" fatigue ("We have to update our code every two months for Firefox, let's forget about them").

So I think we shouldn't contact them before bug 713643 (and if we want to get to them quickly, we should put higher priority on bug 713643).

(Note that we will have exactly the same evangelism problem with gradients, officially CR, but still prefixed in Gecko).
In response to comment 42 - Yes, I was going hold off contact with EA until bug 713643. I did send them an update recently letting them know the status of what's going on (Note: they are watching this bug).
Does this issue remain unresolved on FF14? I think this may be fixed now that we've resolved bug 713643 on FF14 by backing out bug 497995.
Keywords: qawanted
(In reply to Alex Keybl [:akeybl] from comment #44)
> Does this issue remain unresolved on FF14? I think this may be fixed now
> that we've resolved bug 713643 on FF14 by backing out bug 497995.

should be fixed in 14
This appears to be fixed now on Nightly.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.