110804 - gdk exits when try to do "print Preview"

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P1)

Description

[Yuying Long]

Build: 11-19-06 trunk build.

When click the menu item "Print Preview" under file, the browser got crashed.

It was worked fine on 11-16 trunk build.

Comment 1

[sujay]

Rod, looks like we have a regression here...

Comment 2

[rods (gone)]

Will take a look

Comment 3

[Jim Crumley]

WFM with Sparc Solaris build 2001111822.

Comment 4

[dcone (gone)]

this is for you rod.

Comment 5

[rods (gone)]

Just pulled and built and I was able to PP the mozilla.org page.

I need an URL or a stack trace or something

Comment 6

[Yuying Long]

I have this crash with any pages.  And don't know why talkback was not showing
up with this crash, I only see the error message in terminal window:
Gdk-ERROR **: BadMatch (invalid parameter attributes)
  serial 63454 error_code 8 request_code 73 minor_code 0

Comment 7

[ji]

It doesn't crash with 11/16 trunk build, but it does crash on 11/18 trunk build
on my system. Added bstell on cc list.

Comment 8

[kill this account]

may be related to the checkin of bug 90813

Comment 9

[Yuying Long]

Another way:
go: http://www.kdaily.com will see the crash which is same as when I try print
preview - same error message and no talkback pops-up.

Comment 10

[sujay]

Yuying, can you please provide a URL and/or stack trace? thanks.

Comment 11

[ji]

This crash doesn't happen when running browser in C or en_US locale. It crashes
in Japanese locale. That's why only people in intl group see this crash. 

Comment 12

[rods (gone)]

I am not really sure how I can fix this bug

Comment 13

[Shanjian Li]

I will take a look. Take the bug for now. 

Comment 14

[ji]

QA contact to Yuying.

Comment 15

[kill this account]

> Gdk-ERROR **: BadMatch (invalid parameter attributes)
>  serial 63454 error_code 8 request_code 73 minor_code 0

this appears related to the checkin of bug 90813

Comment 16

[Yuying Long]

Change product to intl - not only crash on print preview but also by loading
some web pages. (e.g. kdaily.com)

Comment 17

[kill this account]

Attachment: patch; move test for invalid size to after last time value is set

The test for invalid size was before some of the code that could
update the size.

Comment 18

[kill this account]

*** Bug 110858 has been marked as a duplicate of this bug. ***

Comment 19

[Roy Yokoyama]

Comment on attachment 58571 [details] [diff] [review]
patch; move test for invalid size to after last time value is set

/r=yokoyama

Comment 20

[kill this account]

changed title from:

 [WFM]Linux: Crash when try to do "print Preview"

to:
 gdk exits when try to do "print Preview"

Comment 21

[Adam D. Moss]

I wonder if this fix would also fix the problem that
occured in bug 32736 (in the old deprecated shm code).
Certainly it'd be quite nice to fix bug 32736 now that
we're using blending a bit more heavily under X11 for
aasb fonts.

Comment 22

[kill this account]

> I wonder if this fix would also fix the problem that
> occured in bug 32736 (in the old deprecated shm code).

The code in the bug is definitely unrelated to bug 32736.
I'm only familar with request codes up to 119 so I don't recognize 
the error:

  Gdk-ERROR **: BadMatch (invalid parameter attributes)
    serial 18726 error_code 8 request_code 129 minor_code 4

> Certainly it'd be quite nice to fix bug 32736 now that
> we're using blending a bit more heavily under X11 for
> aasb fonts.

For AA text display I would much prefer to see the Render extension 
used than shared memory since Render knows how to interact well with 
the hardware (ie: avoiding video bus contention).

Comment 23

[kill this account]

> Render knows how to interact well with 
> the hardware (ie: avoiding video bus contention).

oops, I forgot: moz draws text to an off screen buffer so this may not
matter. Still, Xrender removes the need to move the background down to
the client for blending then back up to the server.

Comment 24

[Adam D. Moss]

> oops, I forgot: moz draws text to an off screen buffer so this may not
> matter. Still, Xrender removes the need to move the background down to
> the client for blending then back up to the server.

Sure!  But then, fixing/re-adding shm support for the 'get'
would make the speed of the process suck somewhat less for
the X servers out there which don't have (working) XRender
support (ie. the vast majority of them).

Comment 25

[kill this account]

> the X servers out there which don't have (working) XRender
> support (ie. the vast majority of them).

Is this true?

Comment 26

[Adam D. Moss]

> Is this true?

e.g. of the five X setups I use only one has a (presumably -- untested) working
RENDER set-up, and I'm more often obsessively-upgrading than the average person,
I think.  I'm extrapolating from that.

Comment 27

[kill this account]

the reason I ask is that I'm trying to get an TrueType solution that allows
Xrender but does not require it and I find I'm being beaten soundly about the
head and shoulders for even considering such a thing.

Comment 28

[Adam D. Moss]

Don't get me wrong; I'd be as keen as anyone on a nice TTF solution which is
possibly-independant of RENDER.  I am merely wishing to draw attention to what
looks like relatively-light work which would possibly benefit more users in the
short term.

Comment 29

[Chris Waterson]

Comment on attachment 58571 [details] [diff] [review]
patch; move test for invalid size to after last time value is set

sr=waterson

Comment 30

[kill this account]

checked in

Comment 31

[Yuying Long]

Not reproducible on 11-29 trunk build.

Verified fixed.